![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
И опять про Firebird
А вот еще подняли вуду тему в конференции по FB - типа "вы хоть сами знаете, зачем это все делаете"/"where are you going today".
Там плавно обсуждение перешло к тому, чтомы все умремосновной вектор развития ИТ - это сознательное отупление разработчиков, а микрософт вместо исправления багов и доработки старых фреймворков делает новые, что не позволяет толком сосредоточиться на работе. Если только не развивать двоемыслие в стиле: "везде поддерживаем придурочный ms-oracle-web2.0-cloud-analslavery-iphone-hype, а реально все пишем на коболедельфи".
И я еще раз повторюсь: я не понимаю, чем Firebird так напрягает людей, которые с ним массово не работают. Те кто работают, типа как я - знают недостатки, умеют их обходить и вообще, полностью необъективны. Ну сервер, как сервер, удобный в установке и использовании.
Postgresql вроде нормален, но с ходу я так и не понял - где у него binding parameters и передача данных в бинарном виде? Я сниффером смотрел на общение клиентского приложения(с явно использованными биндинг параметрами) с сервером при вставке данных - тупой плейнтекст гонится с подставленными значениями.
Oracle неприемлем, ибо анальное рабство, хотя поддерживать и его тоже не помешает, для клиентов, у которых кошерные DBA имеются. Читал Тома Кайта, тестировал в 2005 году. Бесит жабой в качестве GUI и системным вуду. Знакомый линуксоид упорно утверждает что Оракл падает раз в месяц, но я ему не верю - по его словам, у него все падает, поэтому все демоны сидят под специальным контроллером, который их перезапускает после падения. Хрен знает что такое, непонятно, то ли разработчики идиоты и софт у них кривой, то ли просто у него стиль использования не такой как у 83%.
MSSQL какое-то вуду, бесит нелогичностью T/SQL. Хотя я его массово использовал, до полноценного использования возможностей СУБД на всю катушку, как с FB, не дошло - очень большие подозрения, что внедрение у клиентов превратилось бы в ад.
DB2 - ни разу не видел и не сталкивался, даже с людьми, которые под него писали, не общался.
Там плавно обсуждение перешло к тому, что
И я еще раз повторюсь: я не понимаю, чем Firebird так напрягает людей, которые с ним массово не работают. Те кто работают, типа как я - знают недостатки, умеют их обходить и вообще, полностью необъективны. Ну сервер, как сервер, удобный в установке и использовании.
Postgresql вроде нормален, но с ходу я так и не понял - где у него binding parameters и передача данных в бинарном виде? Я сниффером смотрел на общение клиентского приложения(с явно использованными биндинг параметрами) с сервером при вставке данных - тупой плейнтекст гонится с подставленными значениями.
Oracle неприемлем, ибо анальное рабство, хотя поддерживать и его тоже не помешает, для клиентов, у которых кошерные DBA имеются. Читал Тома Кайта, тестировал в 2005 году. Бесит жабой в качестве GUI и системным вуду. Знакомый линуксоид упорно утверждает что Оракл падает раз в месяц, но я ему не верю - по его словам, у него все падает, поэтому все демоны сидят под специальным контроллером, который их перезапускает после падения. Хрен знает что такое, непонятно, то ли разработчики идиоты и софт у них кривой, то ли просто у него стиль использования не такой как у 83%.
MSSQL какое-то вуду, бесит нелогичностью T/SQL. Хотя я его массово использовал, до полноценного использования возможностей СУБД на всю катушку, как с FB, не дошло - очень большие подозрения, что внедрение у клиентов превратилось бы в ад.
DB2 - ни разу не видел и не сталкивался, даже с людьми, которые под него писали, не общался.
no subject
Запрос в бинарном виде?
Как вы себе это представляете? О_о
no subject
обработку ошибок для простоты оставляем за кадром
1) Prepare запроса, вход - текст, выход - хендл запроса на сервере.
2) Запрос параметров и полей запроса - вход хендл препаренного запроса, выход - массивы описаний параметров и полей.
3) Установка значения параметра - вход - ссылка на хендл запроса, индекс параметра, и указатель на память где лежит значение, выход - void
4) Выполнение запроса - вход - хендл запроса, выход - void
5) fetch - вход - хендл запроса, выход - 0/1 ("есть ли еще значения"). т.е. MoveNext для итератора.
6) Чтение полей - аналогично установке значений параметров, только память для значения не читатся, а устанавливается
7) Закрытие запроса - хендл на вход.
Подобная реализация сильно облегчает жизнь серверу, которому не нужно каждый раз парсить запрос и значения параметров из текста заново.