3 самые большие проблемы с Firebird

classic Classic list List threaded Threaded
144 messages Options
12345 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yurij


On May 22, 9:12 am, Dmitri Kuzmenko <[hidden email]> wrote:
> Hello, Tonal!
>
> Tonal wrote:
> > Админские:
> > Програмёрские:
> это все не проблемы, а пожелания. Потому как например почти со всеми
> И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось
> что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы.

Таки одним "наследованием таблиц" обойтись сложно. Потом захотят еще
какого-нибудь ООП на уровне сервера и в итоге получится ужос. Там
чисто из теоретических соображений хреновина получается, а делать
практические реализации без теоретической базы - лучше не нужно. Вон в
оракле объектные типы есть, XML всякий есть, расширения - а толку?
Народ как использовал его через BDE с курсорной обработкой и выгрузкой
на клиент, оставшейся со времен фокспро, так и использует.
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Tonal
In reply to this post by Dmitry Kuzmenko-3

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.
Кстати реляции очень стройненько в ФП ложаться. :)
--
Александр Замараев

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Kuzmenko-3

Hello, Tonal!

Tonal wrote:

>> И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось
>> что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы.
>
> Бизнес-смысл прост - сокращение времени кодирования и сложности поддержки.

бизнес-смысл - это соотношение затрат на реализацию фичи и дохода,
полученного от тех кто будет пользоваться фичей.

Теоретически это могло бы быть возможно как оплачиваемый
custom-development, но тут встает уже другой вопрос, на тему ресурсов
и приоритетности фич.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Yemanov
In reply to this post by Dmitry Lendel

Dmitry Lendel wrote:
>
> Напрягает наличие буквы "я" в пути к базе. Создаст пользователь Новая
> папка и суши себе голову.

Ты про сервисы? Вообще-то, для этого есть обходное решение.

> Еще напрягает потеря прав доступа объектов после Alter

Ничего не попутал?


--
Дмитрий Еманов

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Alexey Kovyazin
In reply to this post by Alexey Kovyazin
Спасибо всем за ответы. Продолжаем разговор :)

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 и настаивать на реализации всего
списка. Именно так тонны бесполезных фич кочуют из одного сервера в
другой.

Мне вот хочется возможность писать и подключать плагины для
подключения собственной реализации индексов :)

Опять же, прошу вышеуказанных лиц воздержаться от комментариев.

С уважением,
Алексей Ковязин

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Konstantin R. Beliaev
In reply to this post by Alexey Kovyazin

Alexey Kovyazin wrote:
> Прошу опровергнуть мое мнение и написать если не три, то хотя бы две
> насущные проблемы в Firebird.
1) Напрягает регулярная порча индексов (FB 1.5.5) Не знаю, что не так
может делать моя программа, но через неделю-другую работы после рестора
в логе возникает что-то типа
        Index 3 is corrupt on page 1112965 in table SERIALS (150)

2) Очень долгий бэкап-рестор. Давно смотрю в сторону NBACKUP, но пока
руки не дошли...
(в фоне возникла шальная мысль о неком смешанном бэкапе: в новый файл
копируются не все страницы, как это делает NBACKUP, а только страницы
данных и мета-данных, а индексы строятся в момент "инициализации" базы
:-)) не кидайте помидорами, я шучу (почти) :-))) )

Reply | Threaded
Open this post in threaded view
|

Re: 3 ÓÁÍÙÅ ÂÏÌØÛÉÅ ÐÒÏÂÌÅÍÙ Ó Firebird

Oleg Matveyev
In reply to this post by Alexey Kovyazin

>>2. ëÌÁÓÔÅÒÉÚÕÅÍÏÓÔØ (ÎÅÔ)
>
> óÌÉÛËÏÍ ÛÉÒÏËÏÅ ÐÏÎÑÔÉÅ. îÏ ÓÏÇÌÁÓÅÎ, ÅÓÔØ 2 ÍÏÍÅÎÔÁ - failover
> ËÌÁÓÔÅÒÉÚÁÃÉÑ É ËÌÁÓÔÅÒ ÄÌÑ ÐÏ×ÙÛÅÎÉÑ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ.
> þÔÏ ÎÕÖÎÅÅ (×ÏÐÒÏÓ ËÏ ×ÓÅÍ)?

ËÁË ÕÖÅ ÇÏ×ÏÒÉÌÏÓØ:
ÓÎÁÞÁÌÁ failover
Á ÐÏÔÏÍ ×ÏÚÎÉËÎÅÔ ×ÏÐÒÏÓ: ÓÔÏÉÔ ×ÔÏÒÏÊ ÓÅÒ×ÅÒ "ÚÒÑ". ÐÕÓÔØ ÐÏÍÏÇÁÅÔ
ÐÏ-×ÏÚÍÏÖÎÏÓÔÉ.

:-)

>>ðÒÏÇÒÁÍ£ÒÓËÉÅ:
>>1. ïÔÌÁÄËÁ/ÔÒÁÓÓÉÒÏ×ËÁ ÓÏÈÒÁΣÎÏË É ÔÒÉÎÇÇÅÒÏ×.
>
> TraceAPI? FBScanner CE? MON$? ðÏÞÅÍÕ ËÏÍÂÉÎÁÃÉÑ ÎÅ ÕÄÏ×ÌÅÔ×ÏÒÑÅÔ?
>

ÎÅ, ÒÅÁÌØÎÏ ÏÔÌÁÄÞÉË ÂÙ ÎÅÐÏÍÅÛÁÌ.
Ó ÐÏÛÁÇÏ×ÙÍ ×ÐÏÌÎÅÎÉÅÍ ÚÁÐÒÏÓÏ×, Ó ×ÈÏÄÏÍ × ÔÒÉÇÇÅÒÙ É ÐÒÏÃÅÄÕÒÙ.
ÈÏÔÑ ÏÂÈÏÄÉÍÓÑ É ÂÅÚ ÎÅÇÏ...

P.S. IBE ÎÅ ÐÒÅÄÌÁÇÁÔØ :-)



Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

AZDesign
In reply to this post by Alexey Kovyazin


On 22 май, 11:52, Alexey Kovyazin <[hidden email]> wrote:
> Спасибо всем за ответы. Продолжаем разговор :)
>
> Теперь перейдем к хотелкам.
> Давайте конкретные хотелки, по работе, так сказать. Без ограничений
> фантазии, но только своей фантазии, а не маркетологов.
>

Вот чего давно хочется - это засунуть пользователей в саму БД
Это позволит тиражировать готовые БД. Вроде все для этого подготовлено
- embeded - есть, read-only - есть/
Осталось только закрыть саму БД, чтобы не всякий мог ее открыть.
И когда по миру поползут CD с базами данных, то и популярность птички
повысится.
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Lendel
In reply to this post by Dmitry Yemanov


Привет

>> Еще напрягает потеря прав доступа объектов после Alter
>
> Ничего не попутал?
>
Да нет. Я писал про это. Есть процедура или триггер. Имя длинное. Есть права
у процедуры или триггера. Делаем Alter права пропадают.
Дмитрий


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Yemanov

Dmitry Lendel wrote:
>
> Да нет. Я писал про это. Есть процедура или триггер. Имя длинное. Есть
> права у процедуры или триггера. Делаем Alter права пропадают.

В 2.5 уже нет этой проблемы.


--
Дмитрий Еманов

Reply | Threaded
Open this post in threaded view
|

Re: 3 ÓÁÍÙÅ ÂÏÌØÛÉÅ ÐÒÏÂÌÅÍÙ Ó Firebird

óÁÍÏÈ×ÁÌÏ× çÒÉÇÏÒÉÊ
In reply to this post by AZDesign

> ÷ÏÔ ÞÅÇÏ ÄÁ×ÎÏ ÈÏÞÅÔÓÑ - ÜÔÏ ÚÁÓÕÎÕÔØ ÐÏÌØÚÏ×ÁÔÅÌÅÊ × ÓÁÍÕ âä

ðÏÄÄÅÒÖÉ×ÁÀ! äÌÑ ÔÉÒÁÖÎÏÇÏ ÒÁÓÐÒÏÓÔÒÁÎÅÎÉÑ ÓÕÝÅÓÔ×ÕÀÝÁÑ ÓÈÅÍÁ ÎÅ ÏÞÅÎØ
ÕÄÏÂÎÁ.

ó Õ×ÁÖÅÎÉÅÍ, óÁÍÏÈ×ÁÌÏ× çÒÉÇÏÒÉÊ



Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Vlad Khorsun
In reply to this post by AZDesign

"AZDesign" ...

> Вот чего давно хочется - это засунуть пользователей в саму БД
(1)
> Это позволит тиражировать готовые БД. Вроде все для этого подготовлено
> - embeded - есть, read-only - есть/
> Осталось только закрыть саму БД, чтобы не всякий мог ее открыть.
(2)

    (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
не нужно.

> И когда по миру поползут CD с базами данных, то и популярность птички
> повысится.

    Да-да-да, эти ЦД будут прямо кричать : "У нас Firebird внутри, УРА !"
Не смешите мои туфли...

--
Хорсун Влад


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Tonal
In reply to this post by Alexey Kovyazin

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 ...)

--
Александр Замараев

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yakov Hrebtov-2
In reply to this post by Alexey Kovyazin

Alexey Kovyazin wrote:
> В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том,
> что реальные проблемы в Firebird вообще отсутствуют.

Если допускается отойти от чисто технических проблем, то имхо очень важны:
1. Цельная, легкодоступная документация в удобной форме.
2. Сайт, соответствующий уровню продукта
    (сравните впечатление о firebirdsql.org vs postgresql.org)

Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и
продвижению FB.

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

PEAKTOP
> Если допускается отойти от чисто технических проблем, то имхо очень важны:
> 1. Цельная, легкодоступная документация в удобной форме.

Это ты про firebirdsql.su ? Дык там, по-моему, все в пордке. Понятное
дело, шо неполная, дык время идет и "красных" страниц ужо почти не
осталось.

Да, кстати, надо Игорю сказать, чтобы multilanguage-plugin прикрутил к
DocuWiki. А то это уже начинает походить на нормальную энциклоблю,
пора бы и на другие языки портировать.

> 2. Сайт, соответствующий уровню продукта
>     (сравните впечатление о firebirdsql.org vs postgresql.org)

А вот тут таки да. Шо-то никто не озадачивается ни дизайном, ни
навигацией. И вообще оно похоже на студенческую поделку эпохи
повального увлечения народонаселением хомяками на "народ.ру".

Не, я конечно понимаю желание Firebird Foundation отдать за это кому-
нибудь денег и коронную отмазку в этом случае: "денех нема...". А оно
надо деньги давать, когда есть желающие и просто так помочь ? Лучше на
съэкономленные премию ДЕ или ВХ выписать.
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yurij
In reply to this post by Vlad Khorsun


On May 22, 11:49 am, "Khorsun Vlad" <[hidden email]> wrote:
>     Да-да-да, эти ЦД будут прямо кричать : "У нас Firebird внутри, УРА !"
> Не смешите мои туфли...

 По-моему, тут как раз все правильно: чем больше firebird
используется, тем более вероятность, что программисты выбирающие базу
данных для таких решений выберут его - чисто потому, что они пойдут на
форум/гугл/итд и спросят "а что бы мне использовать для таких целей?".
 Да и технические специалисты, опять же, просто взглянув на содержимое
диска, увидят что там используется. Я, например, используемые движки
баз данных по именам файлов при инсталляции узнаю :)
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yurij
In reply to this post by Tonal


On May 22, 12:04 pm, Tonal <[hidden email]> 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 делать запросы к базе.
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yurij
In reply to this post by Yakov Hrebtov-2


On May 22, 12:11 pm, Yakov Hrebtov <[hidden email]> wrote:
> Alexey Kovyazin wrote:
> > В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том,
> > что реальные проблемы в Firebird вообще отсутствуют.
> Если допускается отойти от чисто технических проблем, то имхо очень важны:
> 1. Цельная, легкодоступная документация в удобной форме.
> 2. Сайт, соответствующий уровню продукта
>     (сравните впечатление о firebirdsql.org vs postgresql.org)
> Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и
> продвижению FB.

Да. Документации практически нет. Информация распространяется за
деньги в виде книг и в виде устной традиции здесь. Я лично почти все
про FB узнал отсюда, а уже потом систематизировал чтением книг.
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Yemanov
In reply to this post by PEAKTOP

PEAKTOP wrote:
>
> Не, я конечно понимаю желание Firebird Foundation отдать за это кому-
> нибудь денег и коронную отмазку в этом случае: "денех нема...". А оно
> надо деньги давать, когда есть желающие и просто так помочь ? Лучше на
> съэкономленные премию ДЕ или ВХ выписать.

Где этот вагон желающих? Кто-либо из них списался с FF или с админами
проекта про этому вопросу? Ы?


--
Дмитрий Еманов

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Alexey Kovyazin
In reply to this post by Yurij
> 1. Хотим.
> 2. Хотим
> 3. Очень сильно хотим.
> 4. Очень сильно хотим. И желательно с выводом типов из типа запроса, а

Вспомнился старый анекдот про еврея, который истово молился о выигрыше
в лотерею, но лотерейный билет не покупал :) Ну может и не в тему
вспомнился.

По теме:
Давайте предметнее - не просто хотим (всё хотеть штаны лопнут :)), а
для какой задачи хотим, и какое улучшение (облегчение :)) наступит от
осуществления хотения.

Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД
вставляем? Или вообще всю :) Далее учим возвращать XML как результат
запроса, кастомизуемые запросы прикручиваем общение на разных портах
(80) и бац - application server родился, да только их и так много,
более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд
ли.

Или внешние языки рассматриваются как одним-махом-решаем-проблему с
недостатками SQL?

Т.е. хотелось бы услышать конкретную историю - что стоит за хотением
именно в вашем случае.



С уважением,
Алексей Ковязин
12345 ... 8