Pull to refresh
3
0
Дегтярёв Евгений @bat

Go/PHP Developer

Send message
Согласен, совсем уж для «самых маленьких», часть касаемая настройки среды и подключения драйвера можно было смело опустить.
То что в делфи использовался win1251 не обязывает использовать его в web, используйте utf8, сэкономите время в будущем.

зы
с чем связан переезд именно на пхп?
Работа с fb через php не очень хорошая идея, в случае нагрузки, конечно. В fb создание соединения, особенно для classic, не дешево и под нагрузкой это будет съедать время + доп нагрузка на сервер БД. Предпочтительнее эту работу доверить сервису с возможностью поддерживать постоянное соединение с БД. Сервис можно написать на том же делфи, пусть он отдает данные по рест, либо напрямую в браузер либо через php.
после обнаружения долгого session_start при хранении сессий в файлах, надо искать долгоиграющий параллельный запрос от того же пользователя, очевидно же
А у ваших детей? У вас нет детей? А у вас точно не будет детей? Вы хотите сначала попробовать все в жизни и только потом заводить детей? Лично мое мнение: вырастить детей — лучшее что можно попробовать сделать в этой жизни. Если у вас есть возможность, постарайтесь не обрекать их на те же муки покупки своего угла. Тут мне вспоминается комментарии bat. Удачи тебе!

Ничего себе у тебя память, коммент был написан 07.01.2010
зы
после каникул хозяева арендованной квартиры сказали что будут ее продавать
еще через 1.5 месяца переехали в свою )
Проблема заключается в том, что используя LIMIT 100000, 30 — mysql вначале пройдется по первым 100000 записям и только потом выберет нужные 30.

Не совсем так. В общем случае, будут выбраны все записи, попадающие под условие where (тут его нет), отсортированы, затем будут отброшены первые 100 тыс записей и выданы следующие 30. Скорее всего, в данном случае сортировки не будет, так как сортировка по индексному полю, но все равно в пустую будут прочитаны 100тыс записей и для них будут выполнены соединения, отсюда и линейный рост времени выполнения.

Избежать этого достаточно просто

Да просто, сортировка и лимит будут выполнены только за счет индекса, но это применимо только к этому запросу. Мне он кажется весьма странным — постраничная лента всех комментариев в базе (мне не понятно зачем это). Если в этот запрос добавить доп условие, например, ограничение по посту, то указанный хак перестанет быть таким эффективным, поскольку в запросе вида
select id from comments where post_id = 123 order by id limit 10000,30
индекс может быть использован либо для сортировки либо ограничения выборки по post_id.
Поддержу, размера массива и кол-во обращений играют роль.

Помится, в Delphi, по крайней мере, до 7 версии было так.
Есть класс TDataSet для наборов данных, в него загружались данные из БД. Данный класс содержит в себе коллекцию полей (Fields), которые предоставляли доступ к значениям полей текущей записи. Доступ к объектам полей по имени, либо через метод FieldByName() либо более простой вариант типа dataset['fieldname']. Вся фишка в том, что эта коллекция построена на основе одного из базовых классов Delpgi — TList, по сути, массив.
Когда, по событию нужно прочитать/изменить поля одной записи, это не проблема. Но, например, если нужно обработать большой набор данных, данная особенность вылазила боком.
Решение, конечно, есть — получить объекты полей один раз перед циклом. Но сам этот факт вызывал искреннее удивление. В виду того, что в Delphi не было встроенных контейнеров типа хэш и множество, ситуация была не единична.
Force.com IDE тихий ужас
пробуй, хуже точно не будет
А вы, автор, маньяк ))
Не увидел варианта «у меня нет смартфона»
зы
n6300 )
не в курсе. как-то попадалась информация, что часть модификаций планируется делать без пересоздания таблицы, какие изменения и в какой версии не помню. возможно что сейчас какие-то изменения происходят без пересоздания, сомневаюсь что все.
с обычными и полнотекстовыми индексами

значит MyISAM
В InnoDb ALTER TABLE приводит к полному пересозданию таблицы.
Складывается впечатление, что ON DUPLICATE KEY UPDATE тот еще костыль.
Не в курсе как это сейчас, но года 1.5-2 назад имели проблему с этой конструкцией при обработке запросов в параллельных транзакциях, т.е. не в режиме autocommit. Проблема проявлялась при одновременном выполнении запросов с одинаковым значением уникального поля в двух разных транзакциях. Подробностей уже не помню, а по сути получалось что одна транзакция изменяла незафиксированные данные другой.
SELECT… WHERE выполняется без блокировки (кроме чтений в режиме изоляции SERIALIZABLE)

В режиме REPEATABLE READ в подзапросе такой запрос по дочерней таблице блокирует обновление родительских записей. неожиданно
В качестве легковестного SQL для программы, которая будет установлена фиг знает где, можно использовать и SQLite.

Тоже вариант.
FB в качестве встроенного сервера выбирают в основном те, кто работал с обычной версией. У FB Embedded есть один весомый плюс — он ничем не отличается от обычного и одно и тоже приложение может работать как с локальной БД так и с удаленной.
никто не советовал FB для домашней страницы, у не него другая ниша.
в нем конечно нет пакетов, партиционирования и пр. но то что заявлено работает и работает предсказуемо.
CDSee (уже 14-я версия есть, но смысла ставить выше 3.11) нет никакого.

полностью поддерживаю, до сих пор пользуюсь у 3.1
в SVN, чтобы проверить работоспособность фичи в ветке в последних актуальных условиях (голова транка), нужно либо замержить ветку в транк, что в нашем случае не вариант, либо замержить транк в ветку, проверить работоспособность, после чего слияние с транком будет _очень_ болезненным, потому что теперь все изменения транка с момента создания ветки будут самостоятельными изменениями ветки

В транк, естественно, мержить не надо. Но не вижу причин не синхронизировать функциональную ветку с транком. Это основной совет как раз для безболезненного слияния с транком.

Information

Rating
Does not participate
Location
Алтайский край, Россия
Registered
Activity

Specialization

Backend Developer
Senior