Re: 3 самые большие проблемы с Firebird
1.Нет ничего типа WAL, undo log или типа того 2. Нет прав на генераторы и udf 3. Внешние объединения токма посредством индексов. MS SQL например hash join использует направо и налево
Re: 3 самые большие проблемы с Firebird
Что-то стеснялся попросить. Но тоже очень хочется посмотреть Если не трудно и не ком. тайна artgal27 (собака) mail.ru Да, ажиотаж просто недецкий А у нас было все просто - если _оно_ работает и не срет в моск, то наплевать на стиль. Но если _оно_ не дай бог начнет _меня_ напрягать - то держите миня семеро :-) Коваленко Дмитрий.
Re: 3 самые большие проблемы с Firebird
"Качановский Дмитрий" сообщил/сообщила в новостях следующее: news:gvocvk$kd...@ger.gmane.org... Что-то стеснялся попросить. Но тоже очень хочется посмотреть Если не трудно и не ком. тайна artgal27 (собака) mail.ru -- С уважением, Галимов Артур Амирзянович. "Фарммедсервис" г. Сочи.
Re: 3 самые большие проблемы с Firebird
Алексей Вишняков пишет: Мне тоже можно полюбопытствовать? С уважением, Вишняков Алексей. 26 мая 2009 г. 15:59 пользователь Taras Kucher написал: Attid пишет: Используем стандарты в разработке - сейчас документ со стандартами на дельфийский код занимает 18 страниц. В начале многие возмущались - привыкли писать для себя. А сейчас ничего, привыкли. 0_0 а можно его почитатаь если это не комтайна ? Можно. Куда бросить, а то твой адрес показывает как "att...@googlemail.com" и я бы тоже очень хотел бы dmi...@kosht.com
Re: 3 самые большие проблемы с Firebird
Мне тоже можно полюбопытствовать? С уважением, Вишняков Алексей. 26 мая 2009 г. 15:59 пользователь Taras Kucher написал: > > Attid пишет: >>> >>> Используем стандарты в разработке - сейчас документ со стандартами на >>> дельфийский код занимает 18 страниц. В начале многие возмущались - >>> привыкли писать для себя. А сейчас ничего, привыкли. >> >> 0_0 а можно его почитатаь если это не комтайна ? > > Можно. Куда бросить, а то твой адрес показывает как "att...@googlemail.com" > > > С уважением, > Тарас Кучер > -- -- Norritt, mailto:norrittmob...@gmail.com
Re: 3 самые большие проблемы с Firebird
Alexey Kovyazin пишет: В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том, что реальные проблемы в Firebird вообще отсутствуют. Ну то есть технические проблемы такого рода, которые напрягали бы разработчика или админа в процессе разработки и эксплуатации. Вот. Прошу опровергнуть мое мнение и написать если не три, то хотя бы две насущные проблемы в Firebird. Нет насущных проблем. Почти 100 автовокзалов автоматизировано на Firebird 1.5.4. Есть и такие, что в режиме 24x7 работают, добрая половина без квалифицированного администрирования. Вкусности, анонсированные в 2.x (типа select from select), манят, но пока и без них нормально. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: 3 самые большие проблемы с Firebird
On May 28, 10:19 am, "Kovalenko Dmitry" wrote: > > Вот ещё момент. Зачастую вернуть спортивную форму БД без backup/ > > restore невозможно. > > Есть мнение, что вернуть спортивную форму Венде тоже нельзя без > переустановки с предварительной интеграцией всех патчей :-) > > Так что это общая проблема :-) Пример неплох, но... Аналоги некорректна в том смысле, что курс реабилитации БД-старушки не рушит связей и не вляет на БД на уровне логики. В Винде же чистка реестра и библиотек с неявными зависимостями может привести к печальным последствиям.
Re: 3 самые большие проблемы с Firebird
Вот ещё момент. Зачастую вернуть спортивную форму БД без backup/ restore невозможно. Есть мнение, что вернуть спортивную форму Венде тоже нельзя без переустановки с предварительной интеграцией всех патчей :-) Так что это общая проблема :-) Коваленко Дмитрий.
Re: 3 самые большие проблемы с Firebird
On May 26, 12:28 pm, Kochmin Alexandr wrote: > у вас программисты с писательским даров все. Чтоб кратко и емко парой > слов описать сущность. Особенно для процедур. Категорически не согласен. Если проект сразу развивает на FB и проддерживается одним/двумя разработчиками это прекрасно. Но в реальной жизни бывают и другие ситуации. В сложным системах будет 20 процедур выставления счёта если понадобиться (утрирую) и всё потому что реалии жизни...
Re: 3 самые большие проблемы с Firebird
26.05.2009 13:59, Taras Kucher пишет: Attid пишет: Используем стандарты в разработке - сейчас документ со стандартами на дельфийский код занимает 18 страниц. В начале многие возмущались - привыкли писать для себя. А сейчас ничего, привыкли. 0_0 а можно его почитатаь если это не комтайна ? А можно мне тоже? starikov.ale...@gmail.com С уважением, Стариков Алексей
Re: 3 самые большие проблемы с Firebird
-- Булычев Алексей http://www.stella-npf.ru Описания таблиц, полей в таблицах и процедур у нас так же обязательны. Но для того, что бы получить описание нужно выполнить лишние телодвижения. А если процедур чуть меньше 400? Для каждой из них читать описание - пол дня не хватит. Я готов сколько угодно работать, лишь бы потом ничего не делать =) Уж лучше сделать удобоваримые названия процедур, чем потом лазить по их описаниям. Эксперт показывает их где только можно. В HTML документации отакож есть.
Re: 3 самые большие проблемы с Firebird
Boulitchev Aleksey пишет: Ладно ещё в начале разработки можно вспомнить что делает та или иная процедура, а вот что делает процедура SP_EMPLOYEE_RGSTRTN_UPD_CALCLTN через два месяца я вспомнил с трудом =) З.Ы. В документации все прописывается, но приходится учитывать что какой русский программист любит читать эту самую документацию =) препроцессор запихивает все в RDB$DESCRIPTION (comment is) Описания таблиц, полей в таблицах и процедур у нас так же обязательны. Но для того, что бы получить описание нужно выполнить лишние телодвижения. А если процедур чуть меньше 400? Для каждой из них читать описание - пол дня не хватит. Я готов сколько угодно работать, лишь бы потом ничего не делать =) Уж лучше сделать удобоваримые названия процедур, чем потом лазить по их описаниям. С уважением, Тарас Кучер
Re: 3 самые большие проблемы с Firebird
Ладно ещё в начале разработки можно вспомнить что делает та или иная процедура, а вот что делает процедура SP_EMPLOYEE_RGSTRTN_UPD_CALCLTN через два месяца я вспомнил с трудом =) З.Ы. В документации все прописывается, но приходится учитывать что какой русский программист любит читать эту самую документацию =) препроцессор запихивает все в RDB$DESCRIPTION (comment is) -- Булычев Алексей http://www.stella-npf.ru
Re: 3 самые большие проблемы с Firebird
Attid пишет: Используем стандарты в разработке - сейчас документ со стандартами на дельфийский код занимает 18 страниц. В начале многие возмущались - привыкли писать для себя. А сейчас ничего, привыкли. 0_0 а можно его почитатаь если это не комтайна ? Отправил на адрес, который указан в группе новостей. С уважением, Тарас Кучер
Re: 3 самые большие проблемы с Firebird
Attid пишет: Используем стандарты в разработке - сейчас документ со стандартами на дельфийский код занимает 18 страниц. В начале многие возмущались - привыкли писать для себя. А сейчас ничего, привыкли. 0_0 а можно его почитатаь если это не комтайна ? Можно. Куда бросить, а то твой адрес показывает как "att...@googlemail.com" С уважением, Тарас Кучер
Re: 3 самые большие проблемы с Firebird
> Используем стандарты в разработке - сейчас документ со стандартами на > дельфийский код занимает 18 страниц. В начале многие возмущались - > привыкли писать для себя. А сейчас ничего, привыкли. 0_0 а можно его почитатаь если это не комтайна ?
Re: 3 самые большие проблемы с Firebird
Kochmin Alexandr пишет: Taras Kucher wrote: У нас действуют следующие правила Таблица называется именем существительным с префиксом TB_, а процедура - существительное и действие, которое над ним выполняется с префиксом SP_. у вас программисты с писательским даров все. Чтоб кратко и емко парой слов описать сущность. Особенно для процедур. А что делать - жить захочешь, не так раскорячишься =) Если сложно описать парой слов что делает процедура - значит разработчик не понимает что она должна делать =) Используем стандарты в разработке - сейчас документ со стандартами на дельфийский код занимает 18 страниц. В начале многие возмущались - привыкли писать для себя. А сейчас ничего, привыкли. С уважением, Тарас Кучер
Re: 3 самые большие проблемы с Firebird
Taras Kucher wrote: У нас действуют следующие правила Таблица называется именем существительным с префиксом TB_, а процедура - существительное и действие, которое над ним выполняется с префиксом SP_. у вас программисты с писательским даров все. Чтоб кратко и емко парой слов описать сущность. Особенно для процедур.
Re: 3 самые большие проблемы с Firebird
Приветствую. 6. Ограничение длинны имён А откуда вылезло такое пожелание? Автогенеримые имена? У меня такая же проблема. Вот только не автогенеримые имена, а есть желание называть таблицы нормальными именами вместо неудобоваримых сокращений. У нас действуют следующие правила Таблица называется именем существительным с префиксом TB_, а процедура - существительное и действие, которое над ним выполняется с префиксом SP_. Сейчас у нас есть таблица бухгалтерских операций TB_ACCOUNTING_OPERATION, таблица статей бухгалтерских операций называется TB_ACCOUNTING_OPERATION_ARTICLE. Процедуры создания/удаления операции называем SP_ACCOUNTING_OPERATION_CREATE и SP_ACCOUNTING_OPERATION_DELETE соответственно. А вот процедуры создания статей бухгалтерских операций приходится уже сокращать до вида SP_ACCOUNT_OPRTN_ARTICLE_CREATE и SP_ACCOUNT_OPRTN_ARTICLE_DELETE. Ладно ещё в начале разработки можно вспомнить что делает та или иная процедура, а вот что делает процедура SP_EMPLOYEE_RGSTRTN_UPD_CALCLTN через два месяца я вспомнил с трудом =) З.Ы. В документации все прописывается, но приходится учитывать что какой русский программист любит читать эту самую документацию =) С уважением, Тарас Кучер
Re: 3 самые большие проблемы с Firebird
"Yurij" ... Про то, что это проблема именно с временными файлами сортировки, я вспомнил только со второ Да, проблема с временными файлами имеет место не только на сервере и не только у ФБ :-D -- Хорсун Влад
Re: 3 самые большие проблемы с Firebird
"Dmitri Kuzmenko" ... Hello, Vlad! Vlad Khorsun wrote: ок, убил. Дык не надо быть даже рядом с fb-team, чтобы на основании имеющихся и легко собираемых исходников сделать такие бинарники. я все время забываю, что даже если никто не компилирует "свои ФБ", то исходники открыты, и это можно сделать. Ага, и я тебе это всё время напоминаю :) -- Хорсун Влад
Re: 3 самые большие проблемы с Firebird
"Dmitry Yemanov" wote: Давай не будем мешать фичи и их реализацию :-) Ты хочешь обеспечить high availability. А уж WAL-ом или nbackup завтра начнет в 10 раз быстрее работать - это не суть важно. Так? Да, ты абсолютно прав :) Просто в свое время когда только появился nbackup я и не только я судя по конференции попытались использовать его для обеспечения этой фичи. На что кто-то из вас (разработчиков) сказал, что nbackup не для того сделан :) Правда давно это было, м.б. я чего-нибудь и путаю :) Обидно, что даже в roadmape к FB 3 про эту тему как-то не понятно :(
Re: 3 самые большие проблемы с Firebird
Hello, ArtGal! ArtGal wrote: Люди как раз этого и хотят - баз с защитой от переноса между серверами, пусть даже и с примитивной защитой. С "примитивной" - лучше не надо. Будут вопли типа "FB легко вскрывается, защита плохая ..." ок, убедили. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
"Dmitri Kuzmenko" сообщил/сообщила в новостях следующее: news:gv67b1$7v...@ger.gmane.org... Люди как раз этого и хотят - баз с защитой от переноса между серверами, пусть даже и с примитивной защитой. С "примитивной" - лучше не надо. Будут вопли типа "FB легко вскрывается, защита плохая ..." -- С уважением, Галимов Артур Амирзянович. "Фарммедсервис" г. Сочи.
Re: 3 самые большие проблемы с Firebird
я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники а) не уперлись б) практически бесполезны (не умеют читать). Шифрованием этим вы себе уже все проели, если честно. "слабое нельзя, а сильное долго делать". Ну и фиг ли? Сильное не делается и перспективы мутные, а слабого так и нет. Твое негодование поддерживаю :) Вопрос только в том, насколько нам критично появиление ли какого-то либо юного кулхацкера со статейкой "Как я аутентификацию/шифрование в ФБ ломал", который начнет п!"§%ть об этом на весь Интернет... Роман
Re: 3 самые большие проблемы с Firebird
Теперь перейдем к хотелкам.
Давайте конкретные хотелки, по работе, так сказать. Без ограничений
фантазии, но только своей фантазии, а не маркетологов.
Недавно познакомился с одной интересной фичей в Оракле - Virtual Private
Database.
Она позволяет назначить на конкретную табличку дополнительный предикат,
который всегда добавляется к каждому запросу к этой табличке (например
RDB$GET_CONTEXT('USER_SESSION', 'MY_SECRET') = '12345678'). Таким
образом можно довольно акуратно разграничить доступ к информации. В
Оракле работает шустро.
Роман
Re: 3 самые большие проблемы с Firebird
> 2. Возможность создавать обычные и агрегатные функции как СП. > 4. возможность работать с кортежами в тексте SQL и параметрах. а мне только этих 2х пунктов не хватает. =)
Re: 3 самые большие проблемы с Firebird
Евгений Килин wrote: Таблицы конечно не пустые, но лично мне очень не хватает WALа :) Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные процедуры. Давай не будем мешать фичи и их реализацию :-) Ты хочешь обеспечить high availability. А уж WAL-ом или nbackup завтра начнет в 10 раз быстрее работать - это не суть важно. Так? -- Дмитрий Еманов
Re: 3 самые большие проблемы с Firebird
1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на восстановлении какого нибудь триггера, а в результате пустые таблицы Ты в этом уверен? Что пустые таблицы? Таблицы конечно не пустые, но лично мне очень не хватает WALа :) Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные процедуры.
Re: 3 самые большие проблемы с Firebird
Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД вставляем? Или вообще всю :) Далее учим возвращать XML как результат запроса, кастомизуемые запросы прикручиваем общение на разных портах (80) и бац - application server родился, да только их и так много, более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд ли. Или внешние языки рассматриваются как одним-махом-решаем-проблему с недостатками SQL? Т.е. хотелось бы услышать конкретную историю - что стоит за хотением именно в вашем случае. Сейчас запускаем один проектик на Оракле (думаю, что годовой оборот счетов выставленых системой несколько сотен миллионов составит). Бизнес-логика там только на PL/SQL, интерфейс на Oracle Forms. Еще один проектик с которым прихо дилось иметь дело (делал аудит, в разработке я не участвовал) на связке Oracle/Oracle Forms имеет годовой "оборот" около трех миллиардов... И нет там никакого аппсервера, если не считать Oracle Forms. А еще мэйнфрэйм-системы в банках и страховых фирмах, с которыми приходилось иметь дело, - так там тоже никаких серверов приложений - бизнес-логика с базой неразделимы. И ниче так - работает!.. Так что я не совсем уверен (а точнее совсем неуверен), что отдельный сервер приложений так необходим. Хотя, в данном случае, думаю, что с точки зрения маркетинга нам бы своя реализация PL/SQL понадобилась, чем какие-то другие языки. Что касается веба, то основным популярным AJAX-библиотекам данные желательно в табличной форма подавать. В случае типичного стэка сервера приложения [на Java] приходится один раз данные из базы конвертировать в объекты, потом из объектов в таблички, отсылать клиенту, получать от клиента таблички, конвертировать в объекты, передавать О/Р-мапперу чтоб опять в таблички конвертировать... Роман
Re: 3 самые большие проблемы с Firebird
On May 22, 12:47 pm, Alexey Kovyazin wrote: > Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД > вставляем? Или вообще всю :) Далее учим возвращать XML как результат > запроса, кастомизуемые запросы прикручиваем общение на разных портах > (80) и бац - application server родился, да только их и так много, > более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд > ли. > Или внешние языки рассматриваются как одним-махом-решаем-проблему с > недостатками SQL? > Т.е. хотелось бы услышать конкретную историю - что стоит за хотением > именно в вашем случае. Ну вот лично мне лень изучать и подключать отдельные апп-сервера, потому что все они безумные. У реляционной модели есть строгая теория и все построенное на ее основе - практически идентично на разных СУБД. А сервера приложений, жаба, дотнет, ооп, ORM, паттерны и прочий трэш - там кто во что горазд, "как архитектор с утра очередную страницу из GoF выкурил". В итоге все равно конечному пользователю показывается таблица, изредка - с вложенными деталями. И если ее получать прямо результатом запроса к FB, а не через десяток слоев на жабо-дотнетах - это гораздо проще и быстрее будет. А уж если сравнить деплоймент решения "FB и клиентская прога" с "FB +сервер приложений+приложение в него+клиентские проги" - это совершенно разные по трудозатратам вещи. Я сейчас как раз занимаюсь тем, что проектирую такую пакость для использования в нескольких проектах поверх fb и mssql, на дотнете. Редкостная печаль, надо сказать.
Re: 3 самые большие проблемы с Firebird
> 1. Хотим. > 2. Хотим > 3. Очень сильно хотим. > 4. Очень сильно хотим. И желательно с выводом типов из типа запроса, а Вспомнился старый анекдот про еврея, который истово молился о выигрыше в лотерею, но лотерейный билет не покупал :) Ну может и не в тему вспомнился. По теме: Давайте предметнее - не просто хотим (всё хотеть штаны лопнут :)), а для какой задачи хотим, и какое улучшение (облегчение :)) наступит от осуществления хотения. Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД вставляем? Или вообще всю :) Далее учим возвращать XML как результат запроса, кастомизуемые запросы прикручиваем общение на разных портах (80) и бац - application server родился, да только их и так много, более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд ли. Или внешние языки рассматриваются как одним-махом-решаем-проблему с недостатками SQL? Т.е. хотелось бы услышать конкретную историю - что стоит за хотением именно в вашем случае. С уважением, Алексей Ковязин
Re: 3 самые большие проблемы с Firebird
On May 22, 12:04 pm, Tonal wrote: > Alexey Kovyazin пишет:>> 3. Репликация (нет) > 1. Внешние языки для СП и триггеров. > 2. Возможность создавать обычные и агрегатные функции как СП. > 3. Уметь возвращать набор записей из UDF. > 4. возможность работать с кортежами в тексте SQL и параметрах. > Например > ...from TBL T where (T.CLASS_ID, T.TYPE_ID) in ( > select C.ID, C.TYPE_ID from CLS where ...) 1. Хотим. 2. Хотим 3. Очень сильно хотим. 4. Очень сильно хотим. И желательно с выводом типов из типа запроса, а то ненаобъявляется их. типа чтобы: declare variable t var; select * from table into :t; автоматически делал t совпадающим с типом кортежа, возвращаемым запросом. 5. Хотим передавать курсоры в UDF, или же из UDF делать запросы к базе.
Re: 3 самые большие проблемы с Firebird
Alexey Kovyazin wrote: В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том, что реальные проблемы в Firebird вообще отсутствуют. Если допускается отойти от чисто технических проблем, то имхо очень важны: 1. Цельная, легкодоступная документация в удобной форме. 2. Сайт, соответствующий уровню продукта (сравните впечатление о firebirdsql.org vs postgresql.org) Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и продвижению FB.
Re: 3 самые большие проблемы с Firebird
Alexey Kovyazin пишет: 3. Репликация (нет) Есть, есть :) FBReplicator, IBReplicator, Microtec CopyCat и др. Давно однако не смотрел. Вот списочек: http://www.firebirdfaq.org/faq249/ Мне понравился DBRE: http://dbre.sourceforge.net/ru/ 6. Ограничение длинны имён А откуда вылезло такое пожелание? Автогенеримые имена? Не только. Схемы ведь не поддерживаются, и в больших базах приходится вводить префиксную систему для логически связанных объектов. 5. Нет прямой возможности узнать домены результата запроса (select cast(1 as D_BOOL)...) из за этого приходится вручную следить за соответствием типов. А как бы хотелось? Интерпретатор, который тип вроде Variant возвращад с RTTI? Хотелось бы уметь получать имя домена. На клиенте по домену можно автоматом применять конвертацию значения в пользовательский тип. Пример - конвертация в bool, другие перечисления или блобы разных видов. Plain text, xml, rtf, xtml, ini - всё это текстовый блоб но обработка на клиенте может очень сильно различаться. 6. Пользовательские агрегатные типы данных (например структурированный адрес). Приходится вставлять группу полей во все таблицы и следить за их согласованием. Зависит от реализации. Тем не менее бывают нужны. :) 7. Наследование таблиц. Есть несколько рукопашных схем реализации. Не видно смысла. Ответил здесь: http://groups.google.ru/group/ru-firebird/msg/333658571273ac4f ИТОГО, проблемы не слишком то большие. Притерлись и привыкли :) Это да. Теперь перейдем к хотелкам. 1. Внешние языки для СП и триггеров. 2. Возможность создавать обычные и агрегатные функции как СП. 3. Уметь возвращать набор записей из UDF. 4. возможность работать с кортежами в тексте SQL и параметрах. Например ...from TBL T where (T.CLASS_ID, T.TYPE_ID) in ( select C.ID, C.TYPE_ID from CLS where ...) -- Александр Замараев
Re: 3 самые большие проблемы с Firebird
Alexey Kovyazin wrote: Прошу опровергнуть мое мнение и написать если не три, то хотя бы две насущные проблемы в Firebird. 1) Напрягает регулярная порча индексов (FB 1.5.5) Не знаю, что не так может делать моя программа, но через неделю-другую работы после рестора в логе возникает что-то типа Index 3 is corrupt on page 1112965 in table SERIALS (150) 2) Очень долгий бэкап-рестор. Давно смотрю в сторону NBACKUP, но пока руки не дошли... (в фоне возникла шальная мысль о неком смешанном бэкапе: в новый файл копируются не все страницы, как это делает NBACKUP, а только страницы данных и мета-данных, а индексы строятся в момент "инициализации" базы :-)) не кидайте помидорами, я шучу (почти) :-))) )
Re: 3 самые большие проблемы с Firebird
On May 22, 9:12 am, Dmitri Kuzmenko wrote: > Hello, Tonal! > > Tonal wrote: > > Админские: > > Програмёрские: > это все не проблемы, а пожелания. Потому как например почти со всеми > И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось > что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы. Таки одним "наследованием таблиц" обойтись сложно. Потом захотят еще какого-нибудь ООП на уровне сервера и в итоге получится ужос. Там чисто из теоретических соображений хреновина получается, а делать практические реализации без теоретической базы - лучше не нужно. Вон в оракле объектные типы есть, XML всякий есть, расширения - а толку? Народ как использовал его через BDE с курсорной обработкой и выгрузкой на клиент, оставшейся со времен фокспро, так и использует.
Re: 3 самые большие проблемы с Firebird
Hello, Tonal! Tonal wrote: Админские: Програмёрские: это все не проблемы, а пожелания. Потому как например почти со всеми "программерскими" проблемами в других серверах иденично. Особенно убил пункт 4 про список параметров в :list. Ну думать же надо, как его сервер-то будет интерпретировать? Как строку, список целых чисел, блоб, ? А если как строку, то почему разделитель обязательно запятая? Идите с этим в комитет ANSI SQL... :-) И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы. Может, в смысле пожеланий, подумать про что-нибудь более интересное и полезное? но в другом топике :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
2. права не по нормальным группам Э-э-э...Роли? Нет, не роли.
Re: 3 самые большие проблемы с Firebird
Slava Ekimov пишет: Длина с одной буквой Н. А количество с одной буквой Л. И проблема с одной буквой М. А ЖИ и ШЫ нужно писать с буквами Жэ и Шэ. :) -- Александр Замараев
Re: 3 самые большие проблемы с Firebird
Длина с одной буквой Н. А количество с одной буквой Л. И проблема с одной буквой М. :-)
Re: 3 самые большие проблемы с Firebird
Alexey Kovyazin пишет: Прошу опровергнуть мое мнение и написать если не три, то хотя бы две насущные проблемы в Firebird. Админские: 1. Мультипроцессорность (обещают) 2. Кластеризуемость (нет) 3. Репликация (нет) 4. Мониторинг производительности (начало решатся в 2-ке) 5. Ручное обновление статистики индексов. 6. Ограничение длинны имён ... Програмёрские: 1. Отладка/трассировка сохранёнок и тринггеров. 2. Ограничение длинны имён. 3. Ограничение длинны списка в выражении IN (1500) 4. Отсутствие параметров в выражении IN (... where T.ID in (:list) где :list - список). Эмулируется сохранёнкой. 5. Нет прямой возможности узнать домены результата запроса (select cast(1 as D_BOOL)...) из за этого приходится вручную следить за соответствием типов. 6. Пользовательские агрегатные типы данных (например структурированный адрес). Приходится вставлять группу полей во все таблицы и следить за их согласованием. 7. Наследование таблиц. Есть несколько рукопашных схем реализации. ... -- Александр Замараев
Re: 3 самые большие проблемы с Firebird
St. Alex wrote: 1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на восстановлении какого нибудь триггера, а в результате пустые таблицы Ты в этом уверен? Что пустые таблицы? -- Дмитрий Еманов
Re: 3 самые большие проблемы с Firebird
Если начинает казаться что с FB есть проблемы, нужно некоторое время поработать с ораклом. Проблемы исчезнут
Re: 3 самые большие проблемы с Firebird
Меня реально напрягает только одна, о которой я ругался много раз, это идиотская политика партии относительно обратной совместимости. А что с ней не так? Нормальная политика. Мне нравится :-) Щас полез посмотреть - а через что сделана отмена запросов в IB Точнее - как именно :) [ibase.h от IB] DSQL_cancel4 [ibase.h от FB2.5] DSQL_unprepare 4 Ну хоть тут сделали по-уму. А то я прям расстроился (причем сильно), когда SQL_NULL перебросили с 590 на 32766 :-) Коваленко Дмитрий.
Re: 3 самые большие проблемы с Firebird
On May 21, 5:34 pm, Alexey Popov wrote: > > Прошу опровергнуть мое мнение и написать если не три, то хотя бы две > > насущные проблемы в Firebird. > Меня реально напрягает только одна, о которой я ругался много раз, это > идиотская политика партии относительно обратной совместимости. В результате > постоянные проблемы на legacy проектах. Странно, по моему, как раз у Firebird с этим все в порядке. > Вторая проблема - у проекта FB нет(не видно) будущего. Это не то чтобы "нет будущего". Это не совсем ясная целевая аудитория проекта. Припыленные админы-линуксоиды ноют на тему "медленно работает, mysql быстрее". Неадекваты, не считающие денег - "ну НАДО ЖЕ использовать Оракл или MSSQL" т.к. это более энтерпрайзно. И общий популярный неадекват на тему "Firebird->Delphi->кустарные наколенные разработки". В общем, основная проблема: проблем нет, поставил, работает - админы считают себя ненужными и нервничают от этого.
Re: 3 самые большие проблемы с Firebird
Alexey Popov wrote: Вторая проблема - у проекта FB нет(не видно) будущего. о чем ты?
Re: 3 самые большие проблемы с Firebird
Меня реально напрягает только одна, о которой я ругался много раз, это идиотская политика партии относительно обратной совместимости. В результате постоянные проблемы на legacy проектах. А что с ней не так? Нормальная политика. Мне нравится :-) legacy пусть работает на legacy. Коваленко Дмитрий.
Re: 3 самые большие проблемы с Firebird
Alexey Kovyazin wrote: В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том, что реальные проблемы в Firebird вообще отсутствуют. Ну то есть технические проблемы такого рода, которые напрягали бы разработчика или админа в процессе разработки и эксплуатации. Вот. Прошу опровергнуть мое мнение и написать если не три, то хотя бы две насущные проблемы в Firebird. Меня реально напрягает только одна, о которой я ругался много раз, это идиотская политика партии относительно обратной совместимости. В результате постоянные проблемы на legacy проектах. Вторая проблема - у проекта FB нет(не видно) будущего.
Re: 3 самые большие проблемы с Firebird
Hello, Alexey! You wrote on Thu, 21 May 2009 05:56:22 -0700 (PDT): [quot Alexey] AK> В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том, AK> что реальные проблемы в Firebird вообще отсутствуют. AK> Ну то есть технические проблемы такого рода, которые напрягали бы AK> разработчика или админа в процессе разработки и эксплуатации.[/quot]небезызвестного Йоу тут нет... :))) -- With best regards, Alex Cherednichenko.
Re: 3 самые большие проблемы с Firebird
1. манифесты и рантаймы Не, это все не то. 0. Его написал не Microsoft. Коваленко Дмитрий.
Re: 3 самые большие проблемы с Firebird
> > 1. манифесты и рантаймы > о-да. я три раза за то, чтобы залинковать все библиотеки статически в экзешник. помню, какой фурор произвел Yaffil своим одним файлом...
Re: 3 самые большие проблемы с Firebird
Прошу опровергнуть мое мнение и написать если не три, то хотя бы две насущные проблемы в Firebird. 1. манифесты и рантаймы -- Булычев Алексей http://www.stella-npf.ru
RE: 3 самые большие проблемы с Firebird
> 1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на > восстановлении какого нибудь триггера, а в результате пустые таблицы И что в таком случае восстанавливать? Таблицы без триггеров? (Если очень надо - всякие dump`ы существуют) > 2. права не по нормальным группам Э-э-э...Роли? > 3. отсутствие (я не нашел) четких рекомендаций как выбирать размеры > базы > количество буферов и прочие настройки. > Довольно неплохие советы даны у Хелен Борри в "Firebird dev. guide"... __ Eioi?iaoey io ESET NOD32 Antivirus, aa?ney aacu aaiiuo neaiaoo? ae?onia 4093 (20090521) __ Niiauaiea i?iaa?aii i?ia?aiiie ESET NOD32 Antivirus. http://www.esetnod32.ru
Re: 3 самые большие проблемы с Firebird
21.05.2009 16:56, Alexey Kovyazin пишет: 1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на восстановлении какого нибудь триггера, а в результате пустые таблицы 2. права не по нормальным группам 3. отсутствие (я не нашел) четких рекомендаций как выбирать размеры базы количество буферов и прочие настройки. вот что с лету вспомнилось. с уважением, Стариков Алексей
3 самые большие проблемы с Firebird
Всем привет, В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том, что реальные проблемы в Firebird вообще отсутствуют. Ну то есть технические проблемы такого рода, которые напрягали бы разработчика или админа в процессе разработки и эксплуатации. Вот. Прошу опровергнуть мое мнение и написать если не три, то хотя бы две насущные проблемы в Firebird. Влада, Диму и Диму попрошу воздержаться от высказывания мнений в этом топике. С уважением, Алексей Ковязин ibsurgeon.blogspot.com
