![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Необъяснимые вещи необъяснимы
В firebird-devel обсуждают новый ABI/API для Firebird.
Вот этот товарищ: http://en.wikipedia.org/wiki/Jim_Starkey навязывает всем свое видение, на тему использования чего-то JDBC-подобного на C++ в качестве базового клиентского API. Остальные кто в лес, кто по дрова - предлагают генерировать API из IDL, использовать plain C апи, кое-кто вспоминает что на улице 2014 год и вообще не помешало бы JSON-апи уже сделать, ссылаются на оракловский OCI и TDS от mssql и прочую чернягу.
Еще один камень преткновения - использование виртуальных функций для чтения значений полей vs чтение напрямую значений из буфера, который прислал сервер при фетче.
По-моему, они все упоролись. Генерировать API хорошая идея, но не из оккультного IDL же.
Впрочем, тут изначально все плохо, т.к. БД по самой своей сути - это динамическая типизация, с вычитыванием схем и результатов парсинга запросов и в конечном итоге оно всегда сводится к мерзости вида "скрестим динамическую типизацию с языками со статической недотипизацией вроде С".
Вот этот товарищ: http://en.wikipedia.org/wiki/Jim_Starkey навязывает всем свое видение, на тему использования чего-то JDBC-подобного на C++ в качестве базового клиентского API. Остальные кто в лес, кто по дрова - предлагают генерировать API из IDL, использовать plain C апи, кое-кто вспоминает что на улице 2014 год и вообще не помешало бы JSON-апи уже сделать, ссылаются на оракловский OCI и TDS от mssql и прочую чернягу.
Еще один камень преткновения - использование виртуальных функций для чтения значений полей vs чтение напрямую значений из буфера, который прислал сервер при фетче.
По-моему, они все упоролись. Генерировать API хорошая идея, но не из оккультного IDL же.
Впрочем, тут изначально все плохо, т.к. БД по самой своей сути - это динамическая типизация, с вычитыванием схем и результатов парсинга запросов и в конечном итоге оно всегда сводится к мерзости вида "скрестим динамическую типизацию с языками со статической недотипизацией вроде С".
no subject
no subject
no subject
Ах, файрберд... любовь всех дельфийских промзобми из айтиотделов при предприятиях, которые торгуют Советскими Приборами. Владельцы таких предприятий когда-то, в 95 году, захватили не автостоянку, и не дом культуры для сдачи под офисы, а поганый Ангар В Промзоне с Краном и Гаражом. Теперь там сидят работнички и работают, делают промышленную Уродливую Хуйню от Отечественного Производителя.
Файрберд. Бесплатное ИДЕ. Иде оно? Да, есть Ебэ Эксперт. Типа бесплатный для жителей exUSSR (типа - все равно же своруете, суки).
Как у него с бэкапами - восстановлениями? Уже починили баг(и), когда бэкап ВНЕЗАПНО мог оказаться невалидным?
Скажите, а с какой целью идентификаторы в базе являются чувствительными к регистру? А делать автоинкрементное поле через триггер - это зачем? Как там с полнотекстовым поиском, к 2014-то году доделали? Чем отличается Классик Сервер от СуперКлассик Сервера?
От файрберда прямо-таки веет этакой кустарщиной. И он НИКОМУ НЕ НУЖЕН НИГДЕ, кроме как на территории exUSSR.
no subject
no subject
А делать автоинкрементное поле через триггер - это зачем?
Видимо за давностью лет я не помню уже, но разве там не генератор цеплялся точно так же как у PostgreSQL и Oracle?
Но да. Эту РСУБД в России знают исключительно благодаря Borland :)
no subject
Я почти из-за этого делал кодогенерацию SQL, собственно - очень много разницы в разных СУБД именно в плане "сгенерить автоинкремент" и "получить значение автоинкрементного поля".