Re: Database file appeares corrupt: то возникает, то пропадает?
Hello, Alex! Alex Cherednichenko wrote: ?? Adapted Plan DK ^^^ ?? PLAN (A NATURAL) DK обнови IBExpert у себя пожалуйста. Ты его таки доконал? :))) не пришлось. я культурно попросил, не помню, примерно пару-тройку месяцев назад. И уже в апреле на курсах, скачавши новую версию (от 8 апреля), обнаружил что для идентичных планов адаптированный план больше не выводится. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
On May 22, 9:12 am, Dmitri Kuzmenko k...@ibase.ru wrote: Hello, Tonal! Tonal wrote: Админские: Програмёрские: это все не проблемы, а пожелания. Потому как например почти со всеми И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы. Таки одним наследованием таблиц обойтись сложно. Потом захотят еще какого-нибудь ООП на уровне сервера и в итоге получится ужос. Там чисто из теоретических соображений хреновина получается, а делать практические реализации без теоретической базы - лучше не нужно. Вон в оракле объектные типы есть, XML всякий есть, расширения - а толку? Народ как использовал его через BDE с курсорной обработкой и выгрузкой на клиент, оставшейся со времен фокспро, так и использует.
Re: FBScanner, бэкап и порт птицы
Dmitry Yemanov wrote: Все тут нормально :-) Сервис именно так запускается сервером. Я и сам озадаченно чесал репу, потом забил, решив что мне пока не до того :-) Кстати, GBAK с ключем -SE почему-то пишет Cannot attach to services manager gbak -B -SE -T -M -G 192.168.0.200/3052:d:\base\xxx.gdb xxx.fbk
Re: FBScanner, бэкап и порт птицы
Hello, Konstantin! Konstantin R. Beliaev wrote: Я и сам озадаченно чесал репу, потом забил, решив что мне пока не до того :-) Кстати, GBAK с ключем -SE почему-то пишет Cannot attach to services manager gbak -B -SE -T -M -G 192.168.0.200/3052:d:\base\xxx.gdb xxx.fbk (вкрадчиво) - а зачем тебе ключ -T ? Хотя он тут ни при чем. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Dmitri Kuzmenko пишет: это все не проблемы, а пожелания. Потому как например почти со всеми программерскими проблемами в других серверах иденично. Дык раз без этого обходимся, то всяко пожелания. :) Просто при их реализации работа админов и прогеров будет несколько эффективнее как мне кажется. :) Особенно убил пункт 4 про список параметров в :list. Ну думать же надо, как его сервер-то будет интерпретировать? Как строку, список целых чисел, блоб, ? А если как строку, то почему разделитель обязательно запятая? Идите с этим в комитет ANSI SQL... :-) Видится несколько путей решения: 1. Научить сервер обрабатывать честные списки в параметрах. 2. Как кусок строки выкушенный из скобок. 3. Добавить стандартную функцию разбирающую строковый список, вызов которой можно указать после оператора IN. В любом из этих случаев сервер может как-то учитывать списковость. :) И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы. Бизнес-смысл прост - сокращение времени кодирования и сложности поддержки. Насколько я понимаю, в очень многих схемах баз у таблиц есть 1-3 шаблонов - наборов одинаковых полей (ID, C_DATE, C_USER, M_DATE, M_USER) + ограничения и триггеры с ними связанные. При создании таблицы нужно обязательно всё это создать. Да и при модификации/использовании часто нужно знать из какого шаблона эта таблица. Сейчас отслеживание всего этого полностью на прогере или делается внешними самописанными скриптами. Может, в смысле пожеланий, подумать про что-нибудь более интересное и полезное? но в другом топике :-) Интересное каждый себе сам определяет однако. :) Мне вот оченна хочется иметь возможности писать СП на каком-нибудь высокоуровневом языке. Python, Ruby или вовсе Erlang, Haskell. Кстати реляции очень стройненько в ФП ложаться. :) -- Александр Замараев
Re: ���-�� ����� � ��� �� ���� ������� ? :)
ÔÏÐÉË: îÕÖÎÙ ÌÉ ÐÒÏÇÒÁÍÍÉÓÔÕ ÎÁ Java/C++/C# ÈÏÒÏÛÉÅ ÚÎÁÎÉÑ ÍÁÔÁÎÁ/ÄÉÓËÒÅÔËÉ/ÄÉÆÆÕÒÏ×? ScuFF åÓÌÉ ×Ù ÚÁÈÏÔÉÔÅ ÎÁÐÉÓÁÔØ Ä×ÉÖÏË ÄÌÑ ÔÒÅÈÍÅÒÎÏÊ ÉÇÒÙ, ÓËÁÖÅÍ, ÎÁ php, ÔÏ ×ÁÍ ÏÂÑÚÁÔÅÌØÎÏ ÐÏÔÒÅÂÕÅÔÓÑ ÚÎÁÎÉÑ ÍÁÔÅÍÁÔÉËÉ. AleksDesker åÓÌÉ ×Ù ÚÁÈÏÔÉÔÅ ÎÁÐÉÓÁÔØ Ä×ÉÖÏË ÄÌÑ ÔÒÅÈÍÅÒÎÏÊ ÉÇÒÙ, ÓËÁÖÅÍ, ÎÁ php, ÔÏ ÄÌÑ ÎÁÞÁÌÁ ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÐÓÉÈÉÁÔÒ.
Re: FBScanner, бэкап и порт птицы
Oleg Matveyev ... Кстати, GBAK с ключем -SE почему-то пишет Cannot attach to services manager gbak -B -SE -T -M -G 192.168.0.200/3052:d:\base\xxx.gdb xxx.fbk Я тебе вчера еще хотел сказать... ты когда бакап через сервисы делаешь... service_mgr ведь у тебя тоже на другом порту. как-то так: -SERVICE 192.168.0.200/3052:service_mgr И вот тут - вопрос на засыпку. а надо ли при этом писать 192.168.0.200/3052:d:\base\xxx.gdb или просто d:\base\xxx.gdb Просто. -- Хорсун Влад PS 1.5.х ф топку !
Re: 3 самые большие проблемы с Firebird
Hello, Tonal! Tonal wrote: И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы. Бизнес-смысл прост - сокращение времени кодирования и сложности поддержки. бизнес-смысл - это соотношение затрат на реализацию фичи и дохода, полученного от тех кто будет пользоваться фичей. Теоретически это могло бы быть возможно как оплачиваемый custom-development, но тут встает уже другой вопрос, на тему ресурсов и приоритетности фич. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Dmitry Lendel wrote: Напрягает наличие буквы я в пути к базе. Создаст пользователь Новая папка и суши себе голову. Ты про сервисы? Вообще-то, для этого есть обходное решение. Еще напрягает потеря прав доступа объектов после Alter Ничего не попутал? -- Дмитрий Еманов
Re: 3 самые большие проблемы с Firebird
Спасибо всем за ответы. Продолжаем разговор :) 1) Баги. Я думаю, про баги говорить особо смысла нет, их поправят как только желающие занесут в трекер... ну, с некоторым лагом, естественно :) 2) Legacy/ Про legacy подход действительно правильный - заточились на 1.5, работайте на 1.5, в чем вопрос-то. Более того, единственно возможный для развивающегося продукта. 3) По замечаниям Tonal Админские: не очнеь понятно, почему это проблемы админа. Проблемы с производительностью и надежностью системы (не только базы), возникающие на стадии эксплуатации, не обязательно порождены админом. Далее, я бы предложил смотреть на 2.5 в качестве текущей версии по фичам. 1. Мультипроцессорность (обещают) 2.5, 3.0, да и сейчас неплохо работает, не жалейте RAM. 2. Кластеризуемость (нет) Слишком широкое понятие. Но согласен, есть 2 момента - failover кластеризация и кластер для повышения производительности. Что нужнее (вопрос ко всем)? 3. Репликация (нет) Есть, есть :) FBReplicator, IBReplicator, Microtec CopyCat и др. 4. Мониторинг производительности (начало решатся в 2-ке) А что бы тут хотелось? 5. Ручное обновление статистики индексов. ok 6. Ограничение длинны имён А откуда вылезло такое пожелание? Автогенеримые имена? ... Програмёрские: 1. Отладка/трассировка сохранёнок и тринггеров. TraceAPI? FBScanner CE? MON$? Почему комбинация не удовлетворяет? 2. Ограничение длинны имён. повтор, см выше. 3. Ограничение длинны списка в выражении IN (1500) Хорошая шутка :) 4. Отсутствие параметров в выражении IN (... where T.ID in (:list) где :list - список). Эмулируется сохранёнкой. Тоже ничего :) 5. Нет прямой возможности узнать домены результата запроса (select cast(1 as D_BOOL)...) из за этого приходится вручную следить за соответствием типов. А как бы хотелось? Интерпретатор, который тип вроде Variant возвращад с RTTI? 6. Пользовательские агрегатные типы данных (например структурированный адрес). Приходится вставлять группу полей во все таблицы и следить за их согласованием. Зависит от реализации. 7. Наследование таблиц. Есть несколько рукопашных схем реализации. Не видно смысла. ИТОГО, проблемы не слишком то большие. Притерлись и привыкли :) Теперь перейдем к хотелкам. Давайте конкретные хотелки, по работе, так сказать. Без ограничений фантазии, но только своей фантазии, а не маркетологов. Только большая просьба не предлагать посмотреть feature matrix серверов вроде Oracle или MSSQL и настаивать на реализации всего списка. Именно так тонны бесполезных фич кочуют из одного сервера в другой. Мне вот хочется возможность писать и подключать плагины для подключения собственной реализации индексов :) Опять же, прошу вышеуказанных лиц воздержаться от комментариев. С уважением, Алексей Ковязин
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
2. ëÌÁÓÔÅÒÉÚÕÅÍÏÓÔØ (ÎÅÔ) óÌÉÛËÏÍ ÛÉÒÏËÏÅ ÐÏÎÑÔÉÅ. îÏ ÓÏÇÌÁÓÅÎ, ÅÓÔØ 2 ÍÏÍÅÎÔÁ - failover ËÌÁÓÔÅÒÉÚÁÃÉÑ É ËÌÁÓÔÅÒ ÄÌÑ ÐÏ×ÙÛÅÎÉÑ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ. þÔÏ ÎÕÖÎÅÅ (×ÏÐÒÏÓ ËÏ ×ÓÅÍ)? ËÁË ÕÖÅ ÇÏ×ÏÒÉÌÏÓØ: ÓÎÁÞÁÌÁ failover Á ÐÏÔÏÍ ×ÏÚÎÉËÎÅÔ ×ÏÐÒÏÓ: ÓÔÏÉÔ ×ÔÏÒÏÊ ÓÅÒ×ÅÒ ÚÒÑ. ÐÕÓÔØ ÐÏÍÏÇÁÅÔ ÐÏ-×ÏÚÍÏÖÎÏÓÔÉ. :-) ðÒÏÇÒÁÍ£ÒÓËÉÅ: 1. ïÔÌÁÄËÁ/ÔÒÁÓÓÉÒÏ×ËÁ ÓÏÈÒÁΣÎÏË É ÔÒÉÎÇÇÅÒÏ×. TraceAPI? FBScanner CE? MON$? ðÏÞÅÍÕ ËÏÍÂÉÎÁÃÉÑ ÎÅ ÕÄÏ×ÌÅÔ×ÏÒÑÅÔ? ÎÅ, ÒÅÁÌØÎÏ ÏÔÌÁÄÞÉË ÂÙ ÎÅÐÏÍÅÛÁÌ. Ó ÐÏÛÁÇÏ×ÙÍ ×ÐÏÌÎÅÎÉÅÍ ÚÁÐÒÏÓÏ×, Ó ×ÈÏÄÏÍ × ÔÒÉÇÇÅÒÙ É ÐÒÏÃÅÄÕÒÙ. ÈÏÔÑ ÏÂÈÏÄÉÍÓÑ É ÂÅÚ ÎÅÇÏ... P.S. IBE ÎÅ ÐÒÅÄÌÁÇÁÔØ :-)
Re: 3 самые большие проблемы с Firebird
On 22 май, 11:52, Alexey Kovyazin alexey.kovya...@gmail.com wrote: Спасибо всем за ответы. Продолжаем разговор :) Теперь перейдем к хотелкам. Давайте конкретные хотелки, по работе, так сказать. Без ограничений фантазии, но только своей фантазии, а не маркетологов. Вот чего давно хочется - это засунуть пользователей в саму БД Это позволит тиражировать готовые БД. Вроде все для этого подготовлено - embeded - есть, read-only - есть/ Осталось только закрыть саму БД, чтобы не всякий мог ее открыть. И когда по миру поползут CD с базами данных, то и популярность птички повысится.
Re: 3 самые большие проблемы с Firebird
Привет Еще напрягает потеря прав доступа объектов после Alter Ничего не попутал? Да нет. Я писал про это. Есть процедура или триггер. Имя длинное. Есть права у процедуры или триггера. Делаем Alter права пропадают. Дмитрий
Re: FBScanner, бэкап и порт птицы
Khorsun Vlad wrote: как-то так: -SERVICE 192.168.0.200/3052:service_mgr И вот тут - вопрос на засыпку. а надо ли при этом писать 192.168.0.200/3052:d:\base\xxx.gdb или просто d:\base\xxx.gdb Просто. gbak -B -SE 192.168.0.200/3052:service_mgr -M -G 192.168.0.200/3052:d:\base\ххх.gdb xxx.fbk При этом на сервере действительно получается правильный путь: C:\FB\bin/gbak -svc_re 1812 1816 1804 -B -V -M -G 192.168.0.200/3052:d:\base\rozn.gdb xxx.fbk -USER SYSDBA -PASSWORD *** (Правда я не послушался совета Влада, но это не помешало :) ) И вот тут - вопрос на засыпку (с) А где можно найти _полное_ описание ключей GBAK ? Так, чтобы для чайников? PS 1.5.х ф топку ! Не все так просто под луной :
Re: 3 самые большие проблемы с Firebird
Dmitry Lendel wrote: Да нет. Я писал про это. Есть процедура или триггер. Имя длинное. Есть права у процедуры или триггера. Делаем Alter права пропадают. В 2.5 уже нет этой проблемы. -- Дмитрий Еманов
Re: 3 ����� ������� �������� � Firebird
÷ÏÔ ÞÅÇÏ ÄÁ×ÎÏ ÈÏÞÅÔÓÑ - ÜÔÏ ÚÁÓÕÎÕÔØ ÐÏÌØÚÏ×ÁÔÅÌÅÊ × ÓÁÍÕ âä ðÏÄÄÅÒÖÉ×ÁÀ! äÌÑ ÔÉÒÁÖÎÏÇÏ ÒÁÓÐÒÏÓÔÒÁÎÅÎÉÑ ÓÕÝÅÓÔ×ÕÀÝÁÑ ÓÈÅÍÁ ÎÅ ÏÞÅÎØ ÕÄÏÂÎÁ. ó Õ×ÁÖÅÎÉÅÍ, óÁÍÏÈ×ÁÌÏ× çÒÉÇÏÒÉÊ
Re: 3 самые большие проблемы с Firebird
AZDesign ... Вот чего давно хочется - это засунуть пользователей в саму БД (1) Это позволит тиражировать готовые БД. Вроде все для этого подготовлено - embeded - есть, read-only - есть/ Осталось только закрыть саму БД, чтобы не всякий мог ее открыть. (2) (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено не нужно. И когда по миру поползут CD с базами данных, то и популярность птички повысится. Да-да-да, эти ЦД будут прямо кричать : У нас Firebird внутри, УРА ! Не смешите мои туфли... -- Хорсун Влад
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. Цельная, легкодоступная документация в удобной форме. 2. Сайт, соответствующий уровню продукта (сравните впечатление о firebirdsql.org vs postgresql.org) Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и продвижению FB.
Re: 3 самые большие проблемы с Firebird
Если допускается отойти от чисто технических проблем, то имхо очень важны: 1. Цельная, легкодоступная документация в удобной форме. Это ты про firebirdsql.su ? Дык там, по-моему, все в пордке. Понятное дело, шо неполная, дык время идет и красных страниц ужо почти не осталось. Да, кстати, надо Игорю сказать, чтобы multilanguage-plugin прикрутил к DocuWiki. А то это уже начинает походить на нормальную энциклоблю, пора бы и на другие языки портировать. 2. Сайт, соответствующий уровню продукта (сравните впечатление о firebirdsql.org vs postgresql.org) А вот тут таки да. Шо-то никто не озадачивается ни дизайном, ни навигацией. И вообще оно похоже на студенческую поделку эпохи повального увлечения народонаселением хомяками на народ.ру. Не, я конечно понимаю желание Firebird Foundation отдать за это кому- нибудь денег и коронную отмазку в этом случае: денех нема А оно надо деньги давать, когда есть желающие и просто так помочь ? Лучше на съэкономленные премию ДЕ или ВХ выписать.
Re: 3 самые большие проблемы с Firebird
On May 22, 11:49 am, Khorsun Vlad hv...@optima.com.ua wrote: Да-да-да, эти ЦД будут прямо кричать : У нас Firebird внутри, УРА ! Не смешите мои туфли... По-моему, тут как раз все правильно: чем больше firebird используется, тем более вероятность, что программисты выбирающие базу данных для таких решений выберут его - чисто потому, что они пойдут на форум/гугл/итд и спросят а что бы мне использовать для таких целей?. Да и технические специалисты, опять же, просто взглянув на содержимое диска, увидят что там используется. Я, например, используемые движки баз данных по именам файлов при инсталляции узнаю :)
Re: 3 самые большие проблемы с Firebird
On May 22, 12:04 pm, Tonal to...@promsoft.ru 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
On May 22, 12:11 pm, Yakov Hrebtov hreb...@gmail.com wrote: Alexey Kovyazin wrote: В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том, что реальные проблемы в Firebird вообще отсутствуют. Если допускается отойти от чисто технических проблем, то имхо очень важны: 1. Цельная, легкодоступная документация в удобной форме. 2. Сайт, соответствующий уровню продукта (сравните впечатление о firebirdsql.org vs postgresql.org) Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и продвижению FB. Да. Документации практически нет. Информация распространяется за деньги в виде книг и в виде устной традиции здесь. Я лично почти все про FB узнал отсюда, а уже потом систематизировал чтением книг.
Re: 3 самые большие проблемы с Firebird
PEAKTOP wrote: Не, я конечно понимаю желание Firebird Foundation отдать за это кому- нибудь денег и коронную отмазку в этом случае: денех нема А оно надо деньги давать, когда есть желающие и просто так помочь ? Лучше на съэкономленные премию ДЕ или ВХ выписать. Где этот вагон желающих? Кто-либо из них списался с FF или с админами проекта про этому вопросу? Ы? -- Дмитрий Еманов
Re: 3 самые большие проблемы с Firebird
1. Хотим. 2. Хотим 3. Очень сильно хотим. 4. Очень сильно хотим. И желательно с выводом типов из типа запроса, а Вспомнился старый анекдот про еврея, который истово молился о выигрыше в лотерею, но лотерейный билет не покупал :) Ну может и не в тему вспомнился. По теме: Давайте предметнее - не просто хотим (всё хотеть штаны лопнут :)), а для какой задачи хотим, и какое улучшение (облегчение :)) наступит от осуществления хотения. Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД вставляем? Или вообще всю :) Далее учим возвращать XML как результат запроса, кастомизуемые запросы прикручиваем общение на разных портах (80) и бац - application server родился, да только их и так много, более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд ли. Или внешние языки рассматриваются как одним-махом-решаем-проблему с недостатками SQL? Т.е. хотелось бы услышать конкретную историю - что стоит за хотением именно в вашем случае. С уважением, Алексей Ковязин
Re: 3 самые большие проблемы с Firebird
On May 22, 12:47 pm, Alexey Kovyazin alexey.kovya...@gmail.com wrote: Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД вставляем? Или вообще всю :) Далее учим возвращать XML как результат запроса, кастомизуемые запросы прикручиваем общение на разных портах (80) и бац - application server родился, да только их и так много, более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд ли. Или внешние языки рассматриваются как одним-махом-решаем-проблему с недостатками SQL? Т.е. хотелось бы услышать конкретную историю - что стоит за хотением именно в вашем случае. Ну вот лично мне лень изучать и подключать отдельные апп-сервера, потому что все они безумные. У реляционной модели есть строгая теория и все построенное на ее основе - практически идентично на разных СУБД. А сервера приложений, жаба, дотнет, ооп, ORM, паттерны и прочий трэш - там кто во что горазд, как архитектор с утра очередную страницу из GoF выкурил. В итоге все равно конечному пользователю показывается таблица, изредка - с вложенными деталями. И если ее получать прямо результатом запроса к FB, а не через десяток слоев на жабо-дотнетах - это гораздо проще и быстрее будет. А уж если сравнить деплоймент решения FB и клиентская прога с FB +сервер приложений+приложение в него+клиентские проги - это совершенно разные по трудозатратам вещи. Я сейчас как раз занимаюсь тем, что проектирую такую пакость для использования в нескольких проектах поверх fb и mssql, на дотнете. Редкостная печаль, надо сказать.
Re: 3 самые большие проблемы с Firebird
PEAKTOP wrote: Если допускается отойти от чисто технических проблем, то имхо очень важны: 1. Цельная, легкодоступная документация в удобной форме. Это ты про firebirdsql.su ? Дык там, по-моему, все в пордке. Понятное дело, шо неполная, дык время идет и красных страниц ужо почти не осталось. Я про цельную полную документацию в первую очередь на английском языке, доступную с официального сайта. Локализация - это, на мой взгляд, значительно менее важно. Для примера: Где новичок должен почитать про приоритет операций? Сколько времени у него займет поиск этой информации? Для сравнения: На главной странице postgresql.org в поле search написать 'precedence'.
Re: 3 самые большие проблемы с Firebird
Вот интересно, с какой целью представитель компании разрабатывающей коммерческий аналогичный продукт задаёт такие вопросы :) А если серьезно, я сталкиваюсь со следующей проблемой 1. Заказчики развиваются и начинают ворочать все большими и большими массивами данных. Проблема не полного использования ресурсов SMTP серверов и отсутствие возможности собрать их несколько в кластер что бы они попыхтели вместе. 2.Редко, хорошо что редко, но портятся базы. В моей практике в 99,8 случаев % виновато железо (сбои памяти, перегрев сервера, выключение питания), в остальных 0.2% портится индекс в таблице где проходит массовые обновления, удаления, вставки (после установки FB 2.04 не встечалось). Но все таки обидно, что приходится тратить время на перебэкапы восстановление, ну тут да же идей нет как бы этому помочь. Скорее всего эта проблема не имеет отношение к FB как к таковому. C уважением, Мещеряков Вадим.
Re: 3 самые большие проблемы с Firebird
Hello, Vadim! You wrote on Fri, 22 May 2009 17:08:19 +0600: VM Проблема не полного использования ресурсов SMTP серверов и отсутствие VM возможности собрать их несколько в кластер что бы они попыхтели вместе. А ты ничё не путаешь? А вместе попыхтеть, это запросто!.. -- With best regards, Alex Cherednichenko.
Re: 3 самые большие проблемы с Firebird
1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на восстановлении какого нибудь триггера, а в результате пустые таблицы Ты в этом уверен? Что пустые таблицы? Таблицы конечно не пустые, но лично мне очень не хватает WALа :) Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные процедуры.
Re: 3 самые большие проблемы с Firebird
Евгений Килин wrote: Таблицы конечно не пустые, но лично мне очень не хватает WALа :) Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные процедуры. Давай не будем мешать фичи и их реализацию :-) Ты хочешь обеспечить high availability. А уж WAL-ом или nbackup завтра начнет в 10 раз быстрее работать - это не суть важно. Так? -- Дмитрий Еманов
Re: 3 самые большие проблемы с Firebird
Hello, Oleg! Oleg Matveyev wrote: как уже говорилось: сначала failover failover делается на раз с любым существующим ИБ-ФБ, прямо сейчас. а потом возникнет вопрос: стоит второй сервер зря. пусть помогает по-возможности. альтернативный пример - IB 2007/2009 SuperServer, который распараллеливается элементарно, в базовом виде на 8 ядер. Так что пожелание кластера должно не только на надежности основываться, но и на масштабируемости, которой не хватает (если не хватает). То есть и на надежности (дублировании) и на масштабируемости. По отдельности пока все ок. не, реально отладчик бы непомешал. с пошаговым вполнением запросов, с входом в триггеры и процедуры. хотя обходимся и без него... на определенном этапе умения отладчик разработчику уже не нужен. Скорее нужен лог трассировки выполнения действий. Даже не так - для понимания, что имено нужно, надо сначала рассмотреть ряд конкретных примеров, ЧТО именно отлаживается. А то может отладчик как раз и нафиг не нужен. Я понятно, теоретизирую, но иногда желаемое называют не тем словом. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Hello, Vlad! Khorsun Vlad wrote: Это позволит тиражировать готовые БД. Вроде все для этого подготовлено - embeded - есть, read-only - есть/ Осталось только закрыть саму БД, чтобы не всякий мог ее открыть. (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено не нужно. причина и следствие попутаны. Пример - IB 2007 EUA: 1. есть проверка пользователей через admin.ib 2. есть проверка пользователей через БД при этом у них наоборот, дубняк в том, что даже в случае 2 сервер все равно тыркается сначала в пункт 1, т.е. без admin.ib не работает. Если это убрать, то Embedded вполне сможет использовать эту схему. В настоящий момент Embedded не проверяет пользователей потому что их негде взять. Будут в базе - будет брать оттуда, почему нет? Люди как раз этого и хотят - баз с защитой от переноса между серверами, пусть даже и с примитивной защитой. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Dmitri Kuzmenko ... Hello, Vlad! Khorsun Vlad wrote: Это позволит тиражировать готовые БД. Вроде все для этого подготовлено - embeded - есть, read-only - есть/ Осталось только закрыть саму БД, чтобы не всякий мог ее открыть. (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено не нужно. причина и следствие попутаны. В где ? Пример - IB 2007 EUA: 1. есть проверка пользователей через admin.ib 2. есть проверка пользователей через БД при этом у них наоборот, дубняк в том, что даже в случае 2 сервер все равно тыркается сначала в пункт 1, т.е. без admin.ib не работает. Если это убрать, то Embedded вполне сможет использовать эту схему. В настоящий момент Embedded не проверяет пользователей потому что их негде взять. Будут в базе - будет брать оттуда, почему нет? Потому что это embedded. Приложение и так имеет полный доступ к телу БД. Люди как раз этого и хотят - баз с защитой от переноса между серверами, пусть даже и с примитивной защитой. Это называется - шифрование, уже надцать раз обсуждали. Помни о том, что FB - open source, так что проприетарные штучки с хорошо спрятанным логином не катят. -- Хорсун Влад
Re: 3 самые большие проблемы с Firebird
2. Возможность создавать обычные и агрегатные функции как СП. 4. возможность работать с кортежами в тексте SQL и параметрах. а мне только этих 2х пунктов не хватает. =)
Re: 3 ����� ������� �������� � Firebird
Hello, Alexey! You wrote on Thu, 21 May 2009 05:56:22 -0700 (PDT): Из трудностей, с которыми столкнулся на практике 1. Система прав - возможность отделить сисдба от админа, группы и т.п. Но вроде активное движение в этй сторону есть. Для крупных проектов сие довольно критично. 2. Схемы 3. Масштабируемость по произоводительности (путем кластеризации?) Пригодилось бы: Материализованные вьюхи Возможность создания агрегатных функциий Шифрация базы Кеш препаренных запросов на сервере Больше типов индексов - к примеру с гистограммой, частичные, битмап Возможность создания зеркал серверов, балансировочные прокси - год назад проскакивала ссылка как это PostgreSQL сделано. Партиционирование, тейблспейсы. -- -=Боюсь огорчить, но результаты Вашего вскрытия...=- With best regards, Nikolay Ponomarenko
Re: Что-то давно у нас не было пятницы ? :)
Hello, All! шик-блеск, от жены программиста: http://itblogs.ru/blogs/bishop/archive/2009/05/22/48913.aspx -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Hello, Vlad! Khorsun Vlad wrote: (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено не нужно. причина и следствие попутаны. В где ? в там. Embedded-у не нужна встроенная в базу аутентификация, потому что он и так без нее работает. Так? эту схему. В настоящий момент Embedded не проверяет пользователей потому что их негде взять. Будут в базе - будет брать оттуда, почему нет? Потому что это embedded. Приложение и так имеет полный доступ к телу БД. похер. Приложение пусть имеет. Люди как раз этого и хотят - баз с защитой от переноса между серверами, пусть даже и с примитивной защитой. Это называется - шифрование, уже надцать раз обсуждали. Помни о том, что FB - open source, так что проприетарные штучки с хорошо спрятанным логином не катят. я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники а) не уперлись б) практически бесполезны (не умеют читать). Шифрованием этим вы себе уже все проели, если честно. слабое нельзя, а сильное долго делать. Ну и фиг ли? Сильное не делается и перспективы мутные, а слабого так и нет. В любом случае даже к шифрованной базе у embedded так и будет полный доступ. Вообще, кстати, одно другому не мешает. Аутентификация в базе imho с шифрованием вообще никак не связана. В FB встроеннойа утентификации нет? Нет. Шифрования нет? Нет. А в IB2009 уже есть и то, и другое. Сначала они аутентификацию сделали, а потом шифрование забубенили. И кому что надо, тот тем и пользуется. p.s. уел? :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Hello, Dmitry! Dmitry Lendel wrote: Поддерживаю. С документацией действительно грустно. Читай про 6.0, а потом начиня с 1.0 до 2.5 это фи. да я не знаю, давно предлагал тупо сп...ить langref и переписать его. И как минимум главная часть была бы готова. А остальное склепать из статей. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Hello, Nikolay! Nikolay Ponomarenko wrote: Возможность создания зеркал серверов, балансировочные прокси - год назад проскакивала ссылка как это PostgreSQL сделано. Партиционирование, тейблспейсы. осмелюсь заметить, что это пальцатые фичи, т.е. интересуют тех, кто не хухры-мухры, а бабло на этом деле зарабатывает, или, как минимум, на железо, администрирование и разработку выделяет неслабую копеечку. В связи с этим вопрос - вот лично Ваша контора на разработку ФБ сколько денег перечислила? Или, сколько она готова дотировать на разработку указанных фич? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: 3 самые большие проблемы с Firebird
Dmitri Kuzmenko wrote: осмелюсь заметить, что это пальцатые фичи, т.е. интересуют тех, кто не хухры-мухры, а бабло на этом деле зарабатывает, или, как минимум, на железо, администрирование и разработку выделяет неслабую копеечку. В связи с этим вопрос - вот лично Ваша контора на разработку ФБ сколько денег перечислила? Или, сколько она готова дотировать на разработку указанных фич Конторы которые неслабые копеечки выделяют, просто покупают оракл и все. Никакая ИТ служба в здравом уме при достаточном финансировании не станет связываться с open source проектом неизвестного статуса.
Re: 3 самые большие проблемы с Firebird
Dmitri Kuzmenko ... Hello, Vlad! Khorsun Vlad wrote: (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено не нужно. причина и следствие попутаны. В где ? в там. Embedded-у не нужна встроенная в базу аутентификация, потому что он и так без нее работает. Так? Да, и ? Я тебя не понимаю - ты кого поправляешь\возражаешь ? эту схему. В настоящий момент Embedded не проверяет пользователей потому что их негде взять. Будут в базе - будет брать оттуда, почему нет? Потому что это embedded. Приложение и так имеет полный доступ к телу БД. похер. Приложение пусть имеет. Делать что-то ради галочки, как это принято в покойной ныне компании, мы не будем. Люди как раз этого и хотят - баз с защитой от переноса между серверами, пусть даже и с примитивной защитой. Это называется - шифрование, уже надцать раз обсуждали. Помни о том, что FB - open source, так что проприетарные штучки с хорошо спрятанным логином не катят. я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники а) не уперлись б) практически бесполезны (не умеют читать). *Я сам* завтра под другим именем выпущу бинарники, которые положат с прибором на всех встроенных пользователей и они (бинарники) разойдутся по инету быстрее чем ты можешь себе представить. Тоже пофиг ? Шифрованием этим вы себе уже все проели, если честно. Это вы нам уже всё им проели. Мне лично оно нафиг не упало, есть вещи поинтереснее, да и нужнее. слабое нельзя, а сильное долго делать. Ну и фиг ли? См. выше про галочки Сильное не делается и перспективы мутные, а слабого так и нет. В любом случае даже к шифрованной базе у embedded так и будет полный доступ. Ключ. Живёт. Отдельно. От. Базы. И. От. Кода. Ась ? Вообще, кстати, одно другому не мешает. Не может быть ! Аутентификация в базе imho с шифрованием вообще никак не связана. Та ты шо ! А я связывал, ай-яй-яй... :-D В FB встроеннойа утентификации нет? Нет. Шифрования нет? Нет. А в IB2009 уже есть и то, и другое. Сначала они аутентификацию сделали Ты хочешь меня на слабо взять ? Или спровоцировать на публичный похер IB ? Так ты и сам чуть выше прекрасно отозвался об их встроеннойа утентификации с дубняком :) а потом шифрование забубенили. Забубенили... наверное ты что-то ещё знаешь... :-D И кому что надо, тот тем и пользуется. Конечно. Лог есть, но пользоваться им не рекомендуют, ибо тормозит... GroupCommit ещё не выкинули или он по-прежнему ломает базы ? Баги GTT ещё никого не достали ? Сказать почему их не правят ? Не потому, что не могут. И даже не потому, что не хотят. А потому - что никому оно не надо. p.s. уел? :-) Чем ? Тем, что мы не борланд ? Что мы делаем не то, что дядя сказал, а то что считаем нужным ? Что мы правим унаследованные от них баги, вместо внесения сомнительных недоделанных фич с новыми багами ? Уел он меня... щаззз ! :) -- Хорсун Влад
Re: 3 самые большие проблемы с Firebird
failover делается на раз с любым существующим ИБ-ФБ, прямо сейчас. Как? или я опять проспал очередную революцию... Программировать прийдется? Если да - то не катит. Нужно, чтобы любой DBA мог просто настроить. Прозрачно для приложения, просто ставим на еще один сервер FB, прописываем обоим в firebird.conf пару ключей и вауля.
Re: 3 самые большие проблемы с Firebird
... балансировочные прокси - год назад проскакивала ссылка как это PostgreSQL сделано. можно подробней, что есть балансировочные прокси ?
Re: 3 ����� ������� �������� � Firebird
Hello, Matylitski! You wrote on Fri, 22 May 2009 19:57:26 +0300: MY Конторы которые неслабые копеечки выделяют, просто покупают оракл и MY все. Никакая ИТ служба в здравом уме при достаточном финансировании не MY станет связываться с open source проектом неизвестного статуса. Спорное утверждение - тот же Skype вот не покупал, а допилил PostgreSQL :) Хотя конечно жизненное :)) -- -=Для того, чтобы слова не расходились с делом, надо молчать и ни_рена не делать=- With best regards, Nikolay Ponomarenko
Re: 3 ����� ������� �������� � Firebird
Hello, Oleg! You wrote on Fri, 22 May 2009 21:51:25 +0400: ... балансировочные прокси - год назад проскакивала ссылка как это PostgreSQL сделано. OM можно подробней, что есть балансировочные прокси ? Уж не знаю, насколько правилен сам термин, но имеется ввиду некий промежуточный софт, который сможет по какому-либо алгоритму, раскидывать пользовательские запросы/транзакции/коннекты по разным физическим серверам. А если пишушие транзакции будут не раскидывать, а согласованно дублироваться, то уже и кластер(один из видов) может выйти :) ЕМНИП несколько вариантов чего-то подобного есть у Постгреса, никак статью на рсусском с какой-то из конференций не найду. -- -=Интеллигенция - это специфическая группа, объединяемая идейностью своих задач и беспочвенностью своих идей - Г.Федотов.=- With best regards, Nikolay Ponomarenko
Re: 3 самые большие проблемы с Firebird
Уж не знаю, насколько правилен сам термин, но имеется ввиду некий промежуточный софт, который сможет по какому-либо алгоритму, раскидывать пользовательские запросы/транзакции/коннекты по разным физическим серверам. А если пишушие транзакции будут не раскидывать, а согласованно дублироваться, то уже и кластер(один из видов) может выйти :) ЕМНИП несколько вариантов чего-то подобного есть у Постгреса, никак статью на рсусском с какой-то из конференций не найду. Этот вариант с Firebird уже давно работает на базе C-JDBC (сам лично проверял). Если не ошибаюсь, то вызов хранимых процедур не поддерживается. Ну и будут проблемы с триггерами, которые срабатывают не только при записи и модифицируют базу. Сейчас это ON CONNECT, но там мысли и на старт транзакции где-то бродили. Роман
Re: 3 самые большие проблемы с Firebird
Теперь перейдем к хотелкам.
Давайте конкретные хотелки, по работе, так сказать. Без ограничений
фантазии, но только своей фантазии, а не маркетологов.
Недавно познакомился с одной интересной фичей в Оракле - Virtual Private
Database.
Она позволяет назначить на конкретную табличку дополнительный предикат,
который всегда добавляется к каждому запросу к этой табличке (например
RDB$GET_CONTEXT('USER_SESSION', 'MY_SECRET') = '12345678'). Таким
образом можно довольно акуратно разграничить доступ к информации. В
Оракле работает шустро.
Роман
Re: 3 самые большие проблемы с Firebird
я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники а) не уперлись б) практически бесполезны (не умеют читать). Шифрованием этим вы себе уже все проели, если честно. слабое нельзя, а сильное долго делать. Ну и фиг ли? Сильное не делается и перспективы мутные, а слабого так и нет. Твое негодование поддерживаю :) Вопрос только в том, насколько нам критично появиление ли какого-то либо юного кулхацкера со статейкой Как я аутентификацию/шифрование в ФБ ломал, который начнет п!§%ть об этом на весь Интернет... Роман
