И опять про 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
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Guardian? :)
no subject
У линуксоидов!
Волшебный надежный опен-сорс, который вылизан до ниточки. Миллиарды тулсов для отслеживания мем-ликов и диких указателей. И демоны, запускаемые под надзирателем, потому что падают.
no subject
Если сколько-нибдуь внимательно просмотреть доку по постгресу, то с препаренными статементами все станет проще препаренной репы.
По поводу остальных двух - Postgres по сравнению с ними выглядит свинством. Увы. MS же за то время, которое я его не видел, стал, чисто по-микрософтовски, неповторимо своеобычен и неоднозначен. В общем, ну его...
no subject
FB - бесит своими исключительными тормозами на элементарнейших запросах и ограниченными возможностями.
Oracle - бесит нестабильностью и замороченностью, перед разработкой и запуском софта всегда нужно консультироваться с админами заказчика, т.к. с большой вероятностью у них стоит именно такой билд, в котором что-то тебе нужное сломано и не работает в принципе, а поставить билд посвежее они могут с радостью, но через погода, после его тестирования у себя.
MS - бесит тем, что это MS )
Каждый выбирает то, что его бесит минимально.
no subject
Если тормозит - скорее всего нужно проверять планы запросов, оптимизатор что-нибудь напутал (но у меня такого давно не было).
no subject
no subject
no subject
no subject
SQL Express 100% совместим по синтаксису со старшим братом, равно как и по формату файлов. Т.е. базы отцепленные от SQL Express на ура цепляются к SQL Server std/ent. И наоборот, если не задействовано фич, которые Express не понимает (сжатие данных, partitions и т.д.)
no subject
no subject
MSSQL, кстати, прекрасен для разработки и администрирования, и клиенты очень ему рады, но дорого + безумная политика лицензирования, ряд клиентов просто не готовы платить столько, для них даем альтернативу MySQL или FB. Качество последних на порядок меньше MSSQL, но жить можно.
В одном долгоживущем продукте (n людей*m лет), в котором я принимал участие, вообще есть адов уровень абстрагирования от DB, через кодогенерацию в т.ч. Посему он свободно поддерживает 4 движка баз данных, причем довольно полноценно, не отказываясь от ХП, constraints, и прочих вкусностей... Так что производитель СУБД по большому счету не важен, для разработчика :)
no subject
no subject
А аргумент "потому что MS" мне как-то до известной :)
С DB2, помнится, мы сталкивались несколько лет назад и вынесли вердикт "при наличии MSDE - не востребовано".
no subject
Запрос в бинарном виде?
Как вы себе это представляете? О_о
no subject
обработку ошибок для простоты оставляем за кадром
1) Prepare запроса, вход - текст, выход - хендл запроса на сервере.
2) Запрос параметров и полей запроса - вход хендл препаренного запроса, выход - массивы описаний параметров и полей.
3) Установка значения параметра - вход - ссылка на хендл запроса, индекс параметра, и указатель на память где лежит значение, выход - void
4) Выполнение запроса - вход - хендл запроса, выход - void
5) fetch - вход - хендл запроса, выход - 0/1 ("есть ли еще значения"). т.е. MoveNext для итератора.
6) Чтение полей - аналогично установке значений параметров, только память для значения не читатся, а устанавливается
7) Закрытие запроса - хендл на вход.
Подобная реализация сильно облегчает жизнь серверу, которому не нужно каждый раз парсить запрос и значения параметров из текста заново.
no subject
У базы от 50 клиентов реалтайм отображение всех срезов + сводки которые формировались из хранимых данных. Полет нормальный на 6 люменевых заводах. База в среднем по 4 гига. Раз в сутки 3х секундки удалялись, а содержимое базы ибо было в блобах сжимается зипом. Еснна своя dll для расшифровки блобов и свой сервис записи и оптимизации базы.
no subject
no subject