3 самые большие проблемы с Firebird
Alexey Kovyazin
В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том,
что реальные проблемы в Firebird вообще отсутствуют.
Ну то есть технические проблемы такого рода, которые напрягали бы
разработчика или админа в процессе разработки и эксплуатации.
Вот.
Прошу опровергнуть мое мнение и написать если не три, то хотя бы две
насущные проблемы в Firebird.
Влада, Диму и Диму попрошу воздержаться от высказывания мнений в этом
топике.
С уважением,
Алексей Ковязин
ibsurgeon.blogspot.com
St. Alex
1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на
восстановлении какого нибудь триггера, а в результате пустые таблицы
2. права не по нормальным группам
3. отсутствие (я не нашел) четких рекомендаций как выбирать размеры базы
количество буферов и прочие настройки.
вот что с лету вспомнилось.
с уважением,
Стариков Алексей
Dmitriy A. Beloshistov
> 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.
Boulitchev Aleksey
> насущные проблемы в Firebird.
1. манифесты и рантаймы
--
Булычев Алексей
http://www.stella-npf.ru
AndreiK
>
> 1. манифесты и рантаймы
>
о-да. я три раза за то, чтобы залинковать все библиотеки статически в
экзешник. помню, какой
фурор произвел Yaffil своим одним файлом...
Kovalenko Dmitry
Не, это все не то.
0. Его написал не Microsoft.
Коваленко Дмитрий.
Alex Cherednichenko
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.
Alexey Popov
Alexey Kovyazin wrote:
> В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том,
> что реальные проблемы в Firebird вообще отсутствуют.
> Ну то есть технические проблемы такого рода, которые напрягали бы
> разработчика или админа в процессе разработки и эксплуатации.
> Вот.
> Прошу опровергнуть мое мнение и написать если не три, то хотя бы две
> насущные проблемы в Firebird.
Меня реально напрягает только одна, о которой я ругался много раз, это
идиотская политика партии относительно обратной совместимости. В результате
постоянные проблемы на legacy проектах.
Вторая проблема - у проекта FB нет(не видно) будущего.
Kovalenko Dmitry
> идиотская политика партии относительно обратной совместимости. В
> результате
> постоянные проблемы на legacy проектах.
А что с ней не так? Нормальная политика. Мне нравится :-)
legacy пусть работает на legacy.
Коваленко Дмитрий.
Kochmin Alexandr
> Вторая проблема - у проекта FB нет(не видно) будущего.
о чем ты?
Yurij
On May 21, 5:34 pm, Alexey Popov <a...@novgorod.net> wrote:
> > Прошу опровергнуть мое мнение и написать если не три, то хотя бы две
> > насущные проблемы в Firebird.
> Меня реально напрягает только одна, о которой я ругался много раз, это
> идиотская политика партии относительно обратной совместимости. В результате
> постоянные проблемы на legacy проектах.
Странно, по моему, как раз у Firebird с этим все в порядке.
> Вторая проблема - у проекта FB нет(не видно) будущего.
Это не то чтобы "нет будущего". Это не совсем ясная целевая аудитория
проекта. Припыленные админы-линуксоиды ноют на тему "медленно
работает, mysql быстрее". Неадекваты, не считающие денег - "ну НАДО ЖЕ
использовать Оракл или MSSQL" т.к. это более энтерпрайзно. И общий
популярный неадекват на тему "Firebird->Delphi->кустарные наколенные
разработки".
В общем, основная проблема: проблем нет, поставил, работает - админы
считают себя ненужными и нервничают от этого.
Kovalenko Dmitry
>> идиотская политика партии относительно обратной совместимости.
> А что с ней не так? Нормальная политика. Мне нравится :-)
Щас полез посмотреть - а через что сделана отмена запросов в IB
Точнее - как именно :)
[ibase.h от IB]
DSQL_cancel 4
[ibase.h от FB2.5]
DSQL_unprepare 4
Ну хоть тут сделали по-уму.
А то я прям расстроился (причем сильно), когда SQL_NULL перебросили с 590 на
32766 :-)
Коваленко Дмитрий.
Александр Свириденков
поработать с ораклом.
Проблемы исчезнут
Dmitry Yemanov
>
> 1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на
> восстановлении какого нибудь триггера, а в результате пустые таблицы
Ты в этом уверен? Что пустые таблицы?
--
Дмитрий Еманов
Tonal
> Прошу опровергнуть мое мнение и написать если не три, то хотя бы две
> насущные проблемы в 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. Наследование таблиц. Есть несколько рукопашных схем реализации.
...
--
Александр Замараев
Slava Ekimov
А количество с одной буквой Л.
И проблема с одной буквой М.
:-)
Tonal
> Длина с одной буквой Н.
> А количество с одной буквой Л.
> И проблема с одной буквой М.
--
Александр Замараев
St. Alex
>> 2. права не по нормальным группам
>
> Э-э-э...Роли?
Dmitri Kuzmenko
Tonal wrote:
> Админские:
> Програмёрские:
это все не проблемы, а пожелания. Потому как например почти со всеми
"программерскими" проблемами в других серверах иденично.
Особенно убил пункт 4 про список параметров в :list. Ну думать же надо,
как его сервер-то будет интерпретировать? Как строку, список целых
чисел, блоб, ? А если как строку, то почему разделитель обязательно
запятая? Идите с этим в комитет ANSI SQL... :-)
И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось
что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы.
Может, в смысле пожеланий, подумать про что-нибудь более интересное
и полезное? но в другом топике :-)
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Dmitry Lendel
Явных причин - нет. Есть доброе бурчание на всякие мелочи.
Напрягает наличие буквы "я" в пути к базе. Создаст пользователь Новая папка
и суши себе голову.
Еще напрягает потеря прав доступа объектов после Alter
Было бы не плохо включать родные утилиты в комплект с графическим
интерфейсом. Меня напрягает каждый раз вспоминать командную строку и ключи к
gfix например.
Дмитрий
Yurij
On May 22, 9:12 am, Dmitri Kuzmenko <k...@ibase.ru> wrote:
> Hello, Tonal!
>
> Tonal wrote:
> > Админские:
> > Програмёрские:
> это все не проблемы, а пожелания. Потому как например почти со всеми
> И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось
> что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы.
Таки одним "наследованием таблиц" обойтись сложно. Потом захотят еще
какого-нибудь ООП на уровне сервера и в итоге получится ужос. Там
чисто из теоретических соображений хреновина получается, а делать
практические реализации без теоретической базы - лучше не нужно. Вон в
оракле объектные типы есть, XML всякий есть, расширения - а толку?
Народ как использовал его через BDE с курсорной обработкой и выгрузкой
на клиент, оставшейся со времен фокспро, так и использует.
Tonal
> это все не проблемы, а пожелания. Потому как например почти со всеми
> "программерскими" проблемами в других серверах иденично.
Просто при их реализации работа админов и прогеров будет несколько
эффективнее как мне кажется. :)
> Особенно убил пункт 4 про список параметров в :list. Ну думать же надо,
> как его сервер-то будет интерпретировать? Как строку, список целых
> чисел, блоб, ? А если как строку, то почему разделитель обязательно
> запятая? Идите с этим в комитет ANSI SQL... :-)
Видится несколько путей решения:
1. Научить сервер обрабатывать честные списки в параметрах.
2. Как кусок строки выкушенный из скобок.
3. Добавить стандартную функцию разбирающую строковый список, вызов
которой можно указать после оператора IN.
В любом из этих случаев сервер может как-то учитывать списковость. :)
> И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось
> что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы.
Бизнес-смысл прост - сокращение времени кодирования и сложности поддержки.
Насколько я понимаю, в очень многих схемах баз у таблиц есть 1-3
шаблонов - наборов одинаковых полей (ID, C_DATE, C_USER, M_DATE, M_USER)
+ ограничения и триггеры с ними связанные.
При создании таблицы нужно обязательно всё это создать.
Да и при модификации/использовании часто нужно знать из какого шаблона
эта таблица.
Сейчас отслеживание всего этого полностью на прогере или делается
внешними самописанными скриптами.
> Может, в смысле пожеланий, подумать про что-нибудь более интересное
> и полезное? но в другом топике :-)
Интересное каждый себе сам определяет однако. :)
Мне вот оченна хочется иметь возможности писать СП на каком-нибудь
высокоуровневом языке. Python, Ruby или вовсе Erlang, Haskell.
Кстати реляции очень стройненько в ФП ложаться. :)
--
Александр Замараев
Tonal
Dmitri Kuzmenko пишет:
> это все не проблемы, а пожелания. Потому как например почти со всеми
> "программерскими" проблемами в других серверах иденично.
Дык раз без этого обходимся, то всяко пожелания. :)
Просто при их реализации работа админов и прогеров будет несколько
эффективнее как мне кажется. :)
> Особенно убил пункт 4 про список параметров в :list. Ну думать же надо,
> как его сервер-то будет интерпретировать? Как строку, список целых
> чисел, блоб, ? А если как строку, то почему разделитель обязательно
> запятая? Идите с этим в комитет ANSI SQL... :-)
Видится несколько путей решения:
1. Научить сервер обрабатывать честные списки в параметрах.
2. Как кусок строки выкушенный из скобок.
3. Добавить стандартную функцию разбирающую строковый список, вызов
которой можно указать после оператора IN.
В любом из этих случаев сервер может как-то учитывать списковость. :)
> И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось
> что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы.
Бизнес-смысл прост - сокращение времени кодирования и сложности поддержки.
Насколько я понимаю, в очень многих схемах баз у таблиц есть 1-3
шаблонов - наборов одинаковых полей (ID, C_DATE, C_USER, M_DATE, M_USER)
+ ограничения и триггеры с ними связанные.
При создании таблицы нужно обязательно всё это создать.
Да и при модификации/использовании часто нужно знать из какого шаблона
эта таблица.
Сейчас отслеживание всего этого полностью на прогере или делается
внешними самописанными скриптами.
> Может, в смысле пожеланий, подумать про что-нибудь более интересное
> и полезное? но в другом топике :-)
Dmitri Kuzmenko
Tonal wrote:
>> И про пункт 7 тоже. Сколько дубинок было сломано на этом, а оказалось
>> что бизнес-смысла в этом нет. Т.е. реализацией пользуются единицы.
>
> Бизнес-смысл прост - сокращение времени кодирования и сложности поддержки.
бизнес-смысл - это соотношение затрат на реализацию фичи и дохода,
полученного от тех кто будет пользоваться фичей.
Теоретически это могло бы быть возможно как оплачиваемый
custom-development, но тут встает уже другой вопрос, на тему ресурсов
и приоритетности фич.
Dmitry Yemanov
>
> Напрягает наличие буквы "я" в пути к базе. Создаст пользователь Новая
> папка и суши себе голову.
Ты про сервисы? Вообще-то, для этого есть обходное решение.
> Еще напрягает потеря прав доступа объектов после Alter
Ничего не попутал?
--
Дмитрий Еманов
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 и настаивать на реализации всего
списка. Именно так тонны бесполезных фич кочуют из одного сервера в
другой.
Мне вот хочется возможность писать и подключать плагины для
подключения собственной реализации индексов :)
Опять же, прошу вышеуказанных лиц воздержаться от комментариев.
С уважением,
Алексей Ковязин
Konstantin R. Beliaev
> Прошу опровергнуть мое мнение и написать если не три, то хотя бы две
> насущные проблемы в Firebird.
может делать моя программа, но через неделю-другую работы после рестора
в логе возникает что-то типа
Index 3 is corrupt on page 1112965 in table SERIALS (150)
2) Очень долгий бэкап-рестор. Давно смотрю в сторону NBACKUP, но пока
руки не дошли...
(в фоне возникла шальная мысль о неком смешанном бэкапе: в новый файл
копируются не все страницы, как это делает NBACKUP, а только страницы
данных и мета-данных, а индексы строятся в момент "инициализации" базы
:-)) не кидайте помидорами, я шучу (почти) :-))) )
Oleg Matveyev
>
> Слишком широкое понятие. Но согласен, есть 2 момента - failover
> кластеризация и кластер для повышения производительности.
> Что нужнее (вопрос ко всем)?
как уже говорилось:
сначала failover
а потом возникнет вопрос: стоит второй сервер "зря". пусть помогает
по-возможности.
:-)
>>Програмёрские:
>>1. Отладка/трассировка сохранёнок и тринггеров.
>
> TraceAPI? FBScanner CE? MON$? Почему комбинация не удовлетворяет?
>
не, реально отладчик бы непомешал.
с пошаговым вполнением запросов, с входом в триггеры и процедуры.
хотя обходимся и без него...
P.S. IBE не предлагать :-)
AZDesign
On 22 май, 11:52, Alexey Kovyazin <alexey.kovya...@gmail.com> wrote:
> Спасибо всем за ответы. Продолжаем разговор :)
>
> Теперь перейдем к хотелкам.
> Давайте конкретные хотелки, по работе, так сказать. Без ограничений
> фантазии, но только своей фантазии, а не маркетологов.
>
Вот чего давно хочется - это засунуть пользователей в саму БД
Это позволит тиражировать готовые БД. Вроде все для этого подготовлено
- embeded - есть, read-only - есть/
Осталось только закрыть саму БД, чтобы не всякий мог ее открыть.
И когда по миру поползут CD с базами данных, то и популярность птички
повысится.
Dmitry Lendel
Привет
>> Еще напрягает потеря прав доступа объектов после Alter
>
> Ничего не попутал?
>
Да нет. Я писал про это. Есть процедура или триггер. Имя длинное. Есть права
у процедуры или триггера. Делаем Alter права пропадают.
Дмитрий
Dmitry Yemanov
>
> Да нет. Я писал про это. Есть процедура или триггер. Имя длинное. Есть
> права у процедуры или триггера. Делаем Alter права пропадают.
В 2.5 уже нет этой проблемы.
--
Дмитрий Еманов
Самохвалов Григорий
Поддерживаю! Для тиражного распространения существующая схема не очень
удобна.
С уважением, Самохвалов Григорий
Khorsun Vlad
> Вот чего давно хочется - это засунуть пользователей в саму БД
(1)
> Это позволит тиражировать готовые БД. Вроде все для этого подготовлено
> - embeded - есть, read-only - есть/
> Осталось только закрыть саму БД, чтобы не всякий мог ее открыть.
(2)
(1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
не нужно.
> И когда по миру поползут CD с базами данных, то и популярность птички
> повысится.
Да-да-да, эти ЦД будут прямо кричать : "У нас Firebird внутри, УРА !"
Не смешите мои туфли...
--
Хорсун Влад
Tonal
>> 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 ...)
--
Александр Замараев
Yakov Hrebtov
> В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том,
> что реальные проблемы в Firebird вообще отсутствуют.
Если допускается отойти от чисто технических проблем, то имхо очень важны:
1. Цельная, легкодоступная документация в удобной форме.
2. Сайт, соответствующий уровню продукта
(сравните впечатление о firebirdsql.org vs postgresql.org)
Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и
продвижению FB.
PEAKTOP
> 1. Цельная, легкодоступная документация в удобной форме.
Это ты про firebirdsql.su ? Дык там, по-моему, все в пордке. Понятное
дело, шо неполная, дык время идет и "красных" страниц ужо почти не
осталось.
Да, кстати, надо Игорю сказать, чтобы multilanguage-plugin прикрутил к
DocuWiki. А то это уже начинает походить на нормальную энциклоблю,
пора бы и на другие языки портировать.
> 2. Сайт, соответствующий уровню продукта
> (сравните впечатление о firebirdsql.org vs postgresql.org)
А вот тут таки да. Шо-то никто не озадачивается ни дизайном, ни
навигацией. И вообще оно похоже на студенческую поделку эпохи
повального увлечения народонаселением хомяками на "народ.ру".
Не, я конечно понимаю желание Firebird Foundation отдать за это кому-
нибудь денег и коронную отмазку в этом случае: "денех нема...". А оно
надо деньги давать, когда есть желающие и просто так помочь ? Лучше на
съэкономленные премию ДЕ или ВХ выписать.
Yurij
On May 22, 11:49 am, "Khorsun Vlad" <hv...@optima.com.ua> wrote:
> Да-да-да, эти ЦД будут прямо кричать : "У нас Firebird внутри, УРА !"
> Не смешите мои туфли...
По-моему, тут как раз все правильно: чем больше firebird
используется, тем более вероятность, что программисты выбирающие базу
данных для таких решений выберут его - чисто потому, что они пойдут на
форум/гугл/итд и спросят "а что бы мне использовать для таких целей?".
Да и технические специалисты, опять же, просто взглянув на содержимое
диска, увидят что там используется. Я, например, используемые движки
баз данных по именам файлов при инсталляции узнаю :)
Yurij
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 делать запросы к базе.
Yurij
Да. Документации практически нет. Информация распространяется за
деньги в виде книг и в виде устной традиции здесь. Я лично почти все
про FB узнал отсюда, а уже потом систематизировал чтением книг.
Dmitry Yemanov
>
> Не, я конечно понимаю желание Firebird Foundation отдать за это кому-
> нибудь денег и коронную отмазку в этом случае: "денех нема...". А оно
> надо деньги давать, когда есть желающие и просто так помочь ? Лучше на
> съэкономленные премию ДЕ или ВХ выписать.
Где этот вагон желающих? Кто-либо из них списался с FF или с админами
проекта про этому вопросу? Ы?
--
Дмитрий Еманов
Alexey Kovyazin
> 2. Хотим
> 3. Очень сильно хотим.
> 4. Очень сильно хотим. И желательно с выводом типов из типа запроса, а
Вспомнился старый анекдот про еврея, который истово молился о выигрыше
в лотерею, но лотерейный билет не покупал :) Ну может и не в тему
вспомнился.
По теме:
Давайте предметнее - не просто хотим (всё хотеть штаны лопнут :)), а
для какой задачи хотим, и какое улучшение (облегчение :)) наступит от
осуществления хотения.
Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД
вставляем? Или вообще всю :) Далее учим возвращать XML как результат
запроса, кастомизуемые запросы прикручиваем общение на разных портах
(80) и бац - application server родился, да только их и так много,
более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд
ли.
Или внешние языки рассматриваются как одним-махом-решаем-проблему с
недостатками SQL?
Т.е. хотелось бы услышать конкретную историю - что стоит за хотением
именно в вашем случае.
С уважением,
Алексей Ковязин
Yurij
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, на дотнете.
Редкостная печаль, надо сказать.
Yakov Hrebtov
>> Если допускается отойти от чисто технических проблем, то имхо очень важны:
>> 1. Цельная, легкодоступная документация в удобной форме.
>
> Это ты про firebirdsql.su ? Дык там, по-моему, все в пордке. Понятное
> дело, шо неполная, дык время идет и "красных" страниц ужо почти не
> осталось.
доступную с официального сайта. Локализация - это, на мой взгляд, значительно
менее важно.
Для примера:
Где новичок должен почитать про приоритет операций?
Сколько времени у него займет поиск этой информации?
Для сравнения:
На главной странице postgresql.org в поле search написать 'precedence'.
Vadim Mescheryakov
коммерческий аналогичный продукт задаёт такие вопросы :)
А если серьезно, я сталкиваюсь со следующей проблемой
1. Заказчики развиваются и начинают ворочать все большими и большими
массивами данных.
Проблема не полного использования ресурсов SMTP серверов и отсутствие
возможности собрать их несколько в кластер что бы они попыхтели вместе.
2.Редко, хорошо что редко, но портятся базы. В моей практике в 99,8 случаев
% виновато железо (сбои памяти, перегрев сервера, выключение питания), в
остальных 0.2% портится индекс в таблице где проходит массовые обновления,
удаления, вставки (после установки FB 2.04 не встечалось). Но все таки
обидно, что приходится тратить время на перебэкапы восстановление, ну тут да
же идей нет как бы этому помочь. Скорее всего эта проблема не имеет
отношение к FB как к таковому.
C уважением,
Мещеряков Вадим.
Alex Cherednichenko
You wrote on Fri, 22 May 2009 17:08:19 +0600:
VM> Проблема не полного использования ресурсов SMTP серверов и отсутствие
VM> возможности собрать их несколько в кластер что бы они попыхтели вместе.
А ты ничё не путаешь?
А вместе попыхтеть, это запросто!..
--
With best regards, Alex Cherednichenko.
Roman Rokytskyy
> Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД
> вставляем? Или вообще всю :) Далее учим возвращать XML как результат
> запроса, кастомизуемые запросы прикручиваем общение на разных портах
> (80) и бац - application server родился, да только их и так много,
> более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд
> ли.
>
> Или внешние языки рассматриваются как одним-махом-решаем-проблему с
> недостатками SQL?
>
> Т.е. хотелось бы услышать конкретную историю - что стоит за хотением
> именно в вашем случае.
Сейчас запускаем один проектик на Оракле (думаю, что годовой оборот
счетов выставленых системой несколько сотен миллионов составит).
Бизнес-логика там только на PL/SQL, интерфейс на Oracle Forms. Еще один
проектик с которым прихо дилось иметь дело (делал аудит, в разработке я
не участвовал) на связке Oracle/Oracle Forms имеет годовой "оборот"
около трех миллиардов... И нет там никакого аппсервера, если не считать
Oracle Forms. А еще мэйнфрэйм-системы в банках и страховых фирмах, с
которыми приходилось иметь дело, - так там тоже никаких серверов
приложений - бизнес-логика с базой неразделимы.
И ниче так - работает!.. Так что я не совсем уверен (а точнее совсем
неуверен), что отдельный сервер приложений так необходим. Хотя, в данном
случае, думаю, что с точки зрения маркетинга нам бы своя реализация
PL/SQL понадобилась, чем какие-то другие языки.
Что касается веба, то основным популярным AJAX-библиотекам данные
желательно в табличной форма подавать. В случае типичного стэка сервера
приложения [на Java] приходится один раз данные из базы конвертировать в
объекты, потом из объектов в таблички, отсылать клиенту, получать от
клиента таблички, конвертировать в объекты, передавать О/Р-мапперу чтоб
опять в таблички конвертировать...
Роман
Евгений Килин
>> восстановлении какого нибудь триггера, а в результате пустые таблицы
>
> Ты в этом уверен? Что пустые таблицы?
Таблицы конечно не пустые, но лично мне очень не хватает WALа :)
Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что
бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные
процедуры.
Dmitry Yemanov
>
> Таблицы конечно не пустые, но лично мне очень не хватает WALа :)
> Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что
> бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные
> процедуры.
Давай не будем мешать фичи и их реализацию :-) Ты хочешь обеспечить high
availability. А уж WAL-ом или nbackup завтра начнет в 10 раз быстрее
работать - это не суть важно. Так?
--
Дмитрий Еманов
Dmitri Kuzmenko
Oleg Matveyev wrote:
> как уже говорилось:
> сначала failover
failover делается на раз с любым существующим ИБ-ФБ, прямо сейчас.
> а потом возникнет вопрос: стоит второй сервер "зря". пусть помогает
> по-возможности.
альтернативный пример - IB 2007/2009 SuperServer, который
распараллеливается элементарно, в базовом виде на 8 ядер.
Так что пожелание кластера должно не только на надежности основываться,
но и на масштабируемости, которой не хватает (если не хватает).
То есть и на надежности (дублировании) и на масштабируемости.
По отдельности пока все ок.
> не, реально отладчик бы непомешал.
> с пошаговым вполнением запросов, с входом в триггеры и процедуры.
> хотя обходимся и без него...
на определенном этапе умения отладчик разработчику уже не нужен. Скорее
нужен лог трассировки выполнения действий. Даже не так - для понимания,
что имено нужно, надо сначала рассмотреть ряд конкретных примеров, ЧТО
именно отлаживается.
А то может отладчик как раз и нафиг не нужен.
Я понятно, теоретизирую, но иногда желаемое называют не тем словом.
Dmitri Kuzmenko
Khorsun Vlad wrote:
>> Это позволит тиражировать готовые БД. Вроде все для этого подготовлено
>> - embeded - есть, read-only - есть/
>> Осталось только закрыть саму БД, чтобы не всякий мог ее открыть.
>
>
> (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
> не нужно.
причина и следствие попутаны. Пример - IB 2007 EUA:
1. есть проверка пользователей через admin.ib
2. есть проверка пользователей через БД
при этом у них наоборот, дубняк в том, что даже в случае 2
сервер все равно тыркается сначала в пункт 1, т.е. без admin.ib
не работает.
Если это убрать, то Embedded вполне сможет использовать
эту схему. В настоящий момент Embedded не проверяет пользователей
потому что их негде взять. Будут в базе - будет брать оттуда, почему
нет?
Люди как раз этого и хотят - баз с защитой от переноса между серверами,
пусть даже и с примитивной защитой.
Khorsun Vlad
>
> 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, так что проприетарные штучки с "хорошо
спрятанным" логином не катят.
--
Хорсун Влад
Attid
а мне только этих 2х пунктов не хватает. =)
Dmitry Lendel
> 1. Цельная, легкодоступная документация в удобной форме.
Поддерживаю. С документацией действительно грустно.
"Читай про 6.0, а потом начиня с 1.0 до 2.5" это фи.
> Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и
> продвижению FB.
Во-во
Дмитрий
Nikolay Ponomarenko
You wrote on Thu, 21 May 2009 05:56:22 -0700 (PDT):
Из трудностей, с которыми столкнулся на практике
1. Система прав - возможность отделить сисдба от админа, группы и т.п. Но
вроде активное движение в этй сторону есть. Для крупных проектов сие
довольно критично.
2. Схемы
3. Масштабируемость по произоводительности (путем кластеризации?)
Пригодилось бы:
Материализованные вьюхи
Возможность создания агрегатных функциий
Шифрация базы
Кеш препаренных запросов на сервере
Больше типов индексов - к примеру с гистограммой, частичные, битмап
Возможность создания "зеркал" серверов, балансировочные прокси - год назад
проскакивала ссылка как это PostgreSQL сделано.
Партиционирование, тейблспейсы.
--
-=Боюсь огорчить, но результаты Вашего вскрытия...=-
With best regards, Nikolay Ponomarenko
Dmitri Kuzmenko
Khorsun Vlad wrote:
>>> (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
>>> не нужно.
>> причина и следствие попутаны.
> В где ?
в там. Embedded-у не нужна встроенная в базу аутентификация,
потому что он и так без нее работает. Так?
>> эту схему. В настоящий момент Embedded не проверяет пользователей
>> потому что их негде взять. Будут в базе - будет брать оттуда, почему
>> нет?
>
> Потому что это embedded. Приложение и так имеет полный доступ
> к телу БД.
похер. Приложение пусть имеет.
>> Люди как раз этого и хотят - баз с защитой от переноса между серверами,
>> пусть даже и с примитивной защитой.
>
> Это называется - шифрование, уже надцать раз обсуждали. Помни
> о том, что FB - open source, так что проприетарные штучки с "хорошо
> спрятанным" логином не катят.
я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники
а) не уперлись
б) практически бесполезны (не умеют читать).
Шифрованием этим вы себе уже все проели, если честно.
"слабое нельзя, а сильное долго делать". Ну и фиг ли?
Сильное не делается и перспективы мутные, а слабого так и нет.
В любом случае даже к шифрованной базе у embedded так и будет
"полный доступ".
Вообще, кстати, одно другому не мешает. Аутентификация в базе
imho с шифрованием вообще никак не связана. В FB встроеннойа
утентификации нет? Нет. Шифрования нет? Нет.
А в IB2009 уже есть и то, и другое. Сначала они аутентификацию
сделали, а потом шифрование забубенили. И кому что надо,
тот тем и пользуется.
p.s. уел? :-)
Dmitri Kuzmenko
Dmitry Lendel wrote:
> Поддерживаю. С документацией действительно грустно.
> "Читай про 6.0, а потом начиня с 1.0 до 2.5" это фи.
да я не знаю, давно предлагал тупо сп...ить langref и переписать его.
И как минимум главная часть была бы готова. А остальное склепать
из статей.
Dmitri Kuzmenko
Nikolay Ponomarenko wrote:
> Возможность создания "зеркал" серверов, балансировочные прокси - год
> назад проскакивала ссылка как это PostgreSQL сделано.
> Партиционирование, тейблспейсы.
осмелюсь заметить, что это "пальцатые" фичи, т.е. интересуют тех,
кто не хухры-мухры, а бабло на этом деле зарабатывает, или,
как минимум, на железо, администрирование и разработку выделяет
неслабую копеечку.
В связи с этим вопрос - вот лично Ваша контора на разработку
ФБ сколько денег перечислила? Или, сколько она готова дотировать
на разработку указанных фич?
Matylitski Yury
> осмелюсь заметить, что это "пальцатые" фичи, т.е. интересуют тех,
> кто не хухры-мухры, а бабло на этом деле зарабатывает, или,
> как минимум, на железо, администрирование и разработку выделяет
> неслабую копеечку.
> В связи с этим вопрос - вот лично Ваша контора на разработку
> ФБ сколько денег перечислила? Или, сколько она готова дотировать
> на разработку указанных фич
Конторы которые неслабые копеечки выделяют, просто покупают оракл и все.
Никакая ИТ служба в здравом уме при достаточном финансировании не станет
связываться с open source проектом неизвестного статуса.
Vlad Khorsun
>
> 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. уел? :-)
Чем ? Тем, что мы не борланд ? Что мы делаем не то, что дядя сказал,
а то что считаем нужным ? Что мы правим унаследованные от них баги,
вместо внесения сомнительных недоделанных фич с новыми багами ?
Уел он меня... щаззз ! :)
--
Хорсун Влад
Oleg Matveyev
Как? или я опять проспал очередную революцию...
Программировать прийдется? Если да - то не катит.
Нужно, чтобы любой DBA мог "просто настроить".
Прозрачно для приложения,
просто ставим на еще один сервер FB,
прописываем обоим в firebird.conf пару ключей и вауля.
Oleg Matveyev
> PostgreSQL сделано.
можно подробней, что есть "балансировочные прокси" ?
Nikolay Ponomarenko
You wrote on Fri, 22 May 2009 20:43:11 +0400:
>> Возможность создания "зеркал" серверов, балансировочные прокси - год
>> назад проскакивала ссылка как это PostgreSQL сделано.
>> Партиционирование, тейблспейсы.
DK> осмелюсь заметить, что это "пальцатые" фичи, т.е. интересуют тех,
DK> кто не хухры-мухры, а бабло на этом деле зарабатывает, или,
DK> как минимум, на железо, администрирование и разработку выделяет
DK> неслабую копеечку.
DK> В связи с этим вопрос - вот лично Ваша контора на разработку
DK> ФБ сколько денег перечислила? Или, сколько она готова дотировать
DK> на разработку указанных фич?
Дим, ну ты прямо сразу на дыбу :)
Непосредственно контора не перечисляла(если что, Коваленко Дима поправит)
ничего. И сомневаюсь, что когда-нибудь перечислит. Тем более вышеозначенные
фичи, этой конторе, не нужны.
Да и делать я их не призывал. Не требовал. Просто написал, что в некоторых
проектах они бы пригодились. Можно ведь по пятницам помечтать?
--
-=Деньги - злo! Для пoдрoбнoй инфoрмации пришлите $10=-
Nikolay Ponomarenko
You wrote on Fri, 22 May 2009 19:57:26 +0300:
MY> Конторы которые неслабые копеечки выделяют, просто покупают оракл и
MY> все. Никакая ИТ служба в здравом уме при достаточном финансировании не
MY> станет связываться с open source проектом неизвестного статуса.
Спорное утверждение - тот же Skype вот не покупал, а "допилил" PostgreSQL :)
Хотя конечно жизненное :))
--
-=Для того, чтобы слова не расходились с делом, надо молчать и ни_рена не
делать=-
Nikolay Ponomarenko
You wrote on Fri, 22 May 2009 21:51:25 +0400:
>> ... балансировочные прокси - год назад проскакивала ссылка как это
>> PostgreSQL сделано.
OM> можно подробней, что есть "балансировочные прокси" ?
Уж не знаю, насколько правилен сам термин, но имеется ввиду некий
промежуточный софт, который сможет по какому-либо алгоритму, раскидывать
пользовательские запросы/транзакции/коннекты по разным физическим серверам.
А если пишушие транзакции будут не раскидывать, а согласованно
дублироваться, то уже и кластер(один из видов) может выйти :)
ЕМНИП несколько вариантов чего-то подобного есть у Постгреса, никак статью
на рсусском с какой-то из конференций не найду.
--
-="Интеллигенция - это специфическая группа, объединяемая идейностью своих
задач и беспочвенностью своих идей" - Г.Федотов.=-
Roman Rokytskyy
> промежуточный софт, который сможет по какому-либо алгоритму, раскидывать
> пользовательские запросы/транзакции/коннекты по разным физическим серверам.
>
> А если пишушие транзакции будут не раскидывать, а согласованно
> дублироваться, то уже и кластер(один из видов) может выйти :)
>
> ЕМНИП несколько вариантов чего-то подобного есть у Постгреса, никак
> статью на рсусском с какой-то из конференций не найду.
Этот вариант с Firebird уже давно работает на базе C-JDBC (сам лично
проверял).
Если не ошибаюсь, то вызов хранимых процедур не поддерживается. Ну и
будут проблемы с триггерами, которые срабатывают не только при записи и
модифицируют базу. Сейчас это ON CONNECT, но там мысли и на старт
транзакции где-то бродили.
Роман
Roman Rokytskyy
> я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники
> а) не уперлись
> б) практически бесполезны (не умеют читать).
>
> Шифрованием этим вы себе уже все проели, если честно.
> "слабое нельзя, а сильное долго делать". Ну и фиг ли?
> Сильное не делается и перспективы мутные, а слабого так и нет.
Твое негодование поддерживаю :)
Вопрос только в том, насколько нам критично появиление ли какого-то либо
юного кулхацкера со статейкой "Как я аутентификацию/шифрование в ФБ
ломал", который начнет п!"§%ть об этом на весь Интернет...
Роман
Roman Rokytskyy
> Теперь перейдем к хотелкам.
> Давайте конкретные хотелки, по работе, так сказать. Без ограничений
> фантазии, но только своей фантазии, а не маркетологов.
Недавно познакомился с одной интересной фичей в Оракле - Virtual Private
Database.
Она позволяет назначить на конкретную табличку дополнительный предикат,
который всегда добавляется к каждому запросу к этой табличке (например
RDB$GET_CONTEXT('USER_SESSION', 'MY_SECRET') = '12345678'). Таким
образом можно довольно акуратно разграничить доступ к информации. В
Оракле работает шустро.
Роман
ArtGal
новостях следующее: news:gv67b1$7v5$1...@ger.gmane.org...
>
> Люди как раз этого и хотят - баз с защитой от переноса между серверами,
> пусть даже и с примитивной защитой.
>
С "примитивной" - лучше не надо.
Будут вопли типа "FB легко вскрывается, защита плохая ..."
--
С уважением,
Галимов Артур Амирзянович.
"Фарммедсервис" г. Сочи.
Kovalenko Dmitry
> ничего.
А я тут при чем?
Лично мы (IBP Team) перечислили пару бутылок коньяка + тонны злобных тестов.
А лишнее бабло я трачу на свои игрушки. Это меня больше вдохновляет и не
оставляет осадка :-)
Коваленко Дмитрий.
Dmitry Lendel
>> Поддерживаю. С документацией действительно грустно.
>> "Читай про 6.0, а потом начиня с 1.0 до 2.5" это фи.
>
> да я не знаю, давно предлагал тупо сп...ить langref и переписать его.
> И как минимум главная часть была бы готова. А остальное склепать
> из статей.
Ну хоть так. Я просто к тому, что можно быть стройным и красивым, но с
небритой рожей и это все портит. Я не первый день имею дело с FB, всего
помнить не получается и вот когда нужно выяснить что-то, начинаю носом
ворошить купу всего, терять время, дергать людей по форумам, а что говорить
про неофитов?
Аргумент, что некому - это не аргумент. Другие смогли? Мало писать хороший
код, расширять функциональность, нужно организовать так, чтобы продукт стал
ЛЮБИМЫМ и ПОПУЛЯРНЫМ. А как это сделать и организовать нужно подсмотреть у
других и попробовать. Написала же Хелен книгу. :-)))
Дмитрий
Kovalenko Dmitry
> это все портит.
Пойти побрится, что ли :-)
Коваленко Дмитрий.
sasha
1) Невосстановимые бэкапы (например когда добавил NOT NULL)
2) Невозможноть переименовать некоторые объекты (например имена таблиц).
3) Слишком малая максимальная длина имён объектов (постоянно не хватало)
Kovalenko Dmitry
Я как то, сто лет назад, тоже плакался... Правда прям так злобно
переименовывать объекты - это чревато неестественной смертью.
Псевдонимы типа нужны, для того чтобы поэтапно ....
Коваленко Дмитрий.
sasha
> переименовывать объекты - это чревато неестественной смертью.
>
> Псевдонимы типа нужны, для того чтобы поэтапно ....
MSSQL же ж может. Правда у него процедуры и триггеры невалидные после
этого. А у нас зато в эксперте можно процедуры и триггеры
закоментировать одной волшебной кнопочкой.
Kovalenko Dmitry
> этого.
Не, "это не наш метод"
Нужна отдельная системная таблица с именами
Что то типа.
--- [OBJECT_NAMES]
NAME_ID (PK)
OBJECT_ID (глобальный ID объектов)
NAME
UNIQUE(OBJECT_ID,NAME)
--- [RELATION_FIELDS]
FIELD_OBJECT_ID
RELATION_OBJECT_ID
MAIN_FIELD_NAME_ID //идентификатор главного имени
(FIELD_OBJECT_ID,MAIN_FIELD_NAME_ID) -> OBJECT_NAMES (OBJECT_ID,NAME_ID)
--------
А то я в детстве придумал названия колонок (ID,CLASS), а потом понял что так
называть не стоило. Но было уже поздно :-)
Коваленко Дмитрий.
Dmitri Kuzmenko
Oleg Matveyev wrote:
>> failover делается на раз с любым существующим ИБ-ФБ, прямо сейчас.
>
> Как? или я опять проспал очередную революцию...
просто failower-кластер не имеет отношения к софту, который
"кластеризуется" таким образом.
> Нужно, чтобы любой DBA мог "просто настроить".
> Прозрачно для приложения,
> просто ставим на еще один сервер FB,
> прописываем обоим в firebird.conf пару ключей и вауля.
даже ничего прописывать не надо:
http://www.ibase.ru/ibinstall/ib7cluster.htm
Только не надо отвечать, что "ведь это же для InterBase!".
Заменяем InterBase на Firebird, с одной поправкой, и все.
Dmitri Kuzmenko
Vlad Khorsun wrote:
>> в там. Embedded-у не нужна встроенная в базу аутентификация,
>> потому что он и так без нее работает. Так?
>
> Да, и ? Я тебя не понимаю - ты кого поправляешь\возражаешь ?
тебе возражаю. Ты сказал, что даже если будет EUA в базе,
Embedded-у она пофиг, потому что он не использует аутентификацию вообще.
Я же говорю наоборот - почему бы Embedded-у не использовать EUA,
если она появится в базе.
>> похер. Приложение пусть имеет.
> Делать что-то ради галочки, как это принято в покойной ныне компании,
> мы не будем.
это не галочка.
> *Я сам* завтра под другим именем выпущу бинарники, которые положат с
> прибором
> на всех "встроенных" пользователей и они (бинарники) разойдутся по инету
> быстрее чем
> ты можешь себе представить.
>
> Тоже пофиг ?
ок, убил.
>> Аутентификация в базе imho с шифрованием вообще никак не связана.
>
> Та ты шо ! А я связывал, ай-яй-яй... :-D
ну тогда мы никогда не дождемся, ни шифрования, ни EUA.
А даже если и дождемся, то это будет настолько сложно использовать,
что никто этим пользоваться не будет.
> Ты хочешь меня на слабо взять ? Или спровоцировать на публичный похер
> IB ?
1 - нет. второе предложение не понял.
> Так ты и сам чуть выше прекрасно отозвался об их "встроеннойа
> утентификации"
> с "дубняком" :)
зато работает же.
>> а потом шифрование забубенили.
> Забубенили... наверное ты что-то ещё знаешь... :-D
просто фигура речи.
Dmitri Kuzmenko
ArtGal wrote:
>> Люди как раз этого и хотят - баз с защитой от переноса между серверами,
>> пусть даже и с примитивной защитой.
>
> С "примитивной" - лучше не надо.
> Будут вопли типа "FB легко вскрывается, защита плохая ..."
ок, убедили.
Dmitri Kuzmenko
Matylitski Yury wrote:
> Конторы которые неслабые копеечки выделяют, просто покупают оракл и все.
> Никакая ИТ служба в здравом уме при достаточном финансировании не станет
> связываться с open source проектом неизвестного статуса.
гм. названия наших клиентов по саппорту (и неклиентов) говорят абсолютно
об обратном.
Попутно вопрос - что для Вас "статус", и как его сделать "известным"?
Vlad Khorsun
>
> Hello, Vlad!
>
> Vlad Khorsun wrote:
>
>>> в там. Embedded-у не нужна встроенная в базу аутентификация,
>>> потому что он и так без нее работает. Так?
>>
>> Да, и ? Я тебя не понимаю - ты кого поправляешь\возражаешь ?
>
> тебе возражаю. Ты сказал, что даже если будет EUA в базе,
> Embedded-у она пофиг, потому что он не использует аутентификацию вообще.
И это правильно. Ибо нет реальных механизмов помешать приложению сделать
с БД то, что ему захочется. Единственный известный мне такой механизм так или
иначе связан с шифрованием.
> Я же говорю наоборот - почему бы Embedded-у не использовать EUA,
> если она появится в базе.
Аналог EUA будет в 3.0 и ты прекрасно это знаешь.
>>> похер. Приложение пусть имеет.
>> Делать что-то ради галочки, как это принято в покойной ныне компании, мы не будем.
>
> это не галочка.
Галочка, именно галочка. Может с маркетоложеской точки зрения это великое
свершение, но в действительности это галочка :)
>> *Я сам* завтра под другим именем выпущу бинарники, которые положат с прибором
>> на всех "встроенных" пользователей и они (бинарники) разойдутся по инету быстрее чем
>> ты можешь себе представить.
>>
>> Тоже пофиг ?
>
> ок, убил.
Дык не надо быть даже рядом с fb-team, чтобы на основании имеющихся и
легко собираемых исходников сделать такие бинарники.
>>> Аутентификация в базе imho с шифрованием вообще никак не связана.
>>
>> Та ты шо ! А я связывал, ай-яй-яй... :-D
>
> ну тогда мы никогда не дождемся, ни шифрования, ни EUA.
Шифрованием заниматься у меня охоту отбили напрочь. Не без участия этой
конференции. Насчёт хранения юзеров - в 3.0 будет
> А даже если и дождемся, то это будет настолько сложно использовать,
> что никто этим пользоваться не будет.
Ась ?
>> Ты хочешь меня на слабо взять ? Или спровоцировать на публичный похер IB ?
>
> 1 - нет. второе предложение не понял.
Это было бы о качестве, а не о количестве фич... ну да ладно, проехали
>> Так ты и сам чуть выше прекрасно отозвался об их "встроеннойа утентификации"
>> с "дубняком" :)
>
> зато работает же.
Галочки, галочки... :)
>>> а потом шифрование забубенили.
>> Забубенили... наверное ты что-то ещё знаешь... :-D
>
> просто фигура речи.
Очень она к месту была, Фрейд вмешался ? :)
--
Хорсун Влад
Yurij
On May 24, 4:30 pm, "Vlad Khorsun" <hv...@optima.com.ua> wrote:
> "Dmitri Kuzmenko" ...
> > ну тогда мы никогда не дождемся, ни шифрования, ни EUA.
> Шифрованием заниматься у меня охоту отбили напрочь. Не без участия этой
> конференции. Насчёт хранения юзеров - в 3.0 будет
Что-то я уже забыл, а на чем тогда спор про шифрование закончился? Не
тем же самым, как сейчас: "идеально сделать нельзя, а кое-как - лучше
и не надо".
Yurij
On May 24, 4:13 pm, Dmitri Kuzmenko <k...@ibase.ru> wrote:
> Hello, Yury!
> > Конторы которые неслабые копеечки выделяют, просто покупают оракл и все.
> > Никакая ИТ служба в здравом уме при достаточном финансировании не станет
> > связываться с open source проектом неизвестного статуса.
>
> гм. названия наших клиентов по саппорту (и неклиентов) говорят абсолютно
> об обратном.
>
> Попутно вопрос - что для Вас "статус", и как его сделать "известным"?
Статус - это когда у ИТ-служб не будет возникать тупых вопросов("а
что это такое", "а почему не Oracle", "PostgreSQL лучше") при
упоминании что проект использует Firebird.
sasha
Евгений Килин
> Давай не будем мешать фичи и их реализацию :-) Ты хочешь обеспечить high
> availability. А уж WAL-ом или nbackup завтра начнет в 10 раз быстрее
> работать - это не суть важно. Так?
Да, ты абсолютно прав :)
Просто в свое время когда только появился nbackup я и не только я судя по
конференции попытались использовать его для обеспечения этой фичи. На что
кто-то из вас (разработчиков) сказал, что nbackup не для того сделан :)
Правда давно это было, м.б. я чего-нибудь и путаю :)
Обидно, что даже в roadmape к FB 3 про эту тему как-то не понятно :(
Dmitry Yemanov
>
>>> failover делается на раз с любым существующим ИБ-ФБ, прямо сейчас.
>>
>> Как? или я опять проспал очередную революцию...
>
> просто failower-кластер не имеет отношения к софту, который
> "кластеризуется" таким образом.
Еще как имеет, если это нормальный кластер.
Вариант с общим диском отнюдь не единственный возможный и не самый
лучший (какой это нафиг failover, если винт с базой сдохнет?) Да и не
виндой единой. Так что ссылка идет лесом, IMHO.
--
Дмитрий Еманов
Nikolay Ponomarenko
You wrote on Fri, 22 May 2009 20:50:05 +0200:
RR> Этот вариант с Firebird уже давно работает на базе C-JDBC (сам лично
RR> проверял).
А с транзакциями оно как разбирается? Двухфазный коммит?
--
-=Если отладка - уничтожение багов, то программирование - их создание=-
Nikolay Ponomarenko
You wrote on Sat, 23 May 2009 11:43:00 +0400:
>> Непосредственно контора не перечисляла (если что, Коваленко Дима
>> поправит) ничего.
KD> А я тут при чем?
Имелся ввиду твой тезка, который киевский Дима Коваленко :)
--
-=Женщина с красивыми зубами все находит смешным.=-
Dmitri Kuzmenko
Dmitry Yemanov wrote:
>> просто failower-кластер не имеет отношения к софту, который
>> "кластеризуется" таким образом.
>
> Еще как имеет, если это нормальный кластер.
>
> Вариант с общим диском отнюдь не единственный возможный и не самый
> лучший (какой это нафиг failover, если винт с базой сдохнет?) Да и не
> виндой единой. Так что ссылка идет лесом, IMHO.
Давай так. Существует туча разновидностей кластеров.
Самый тупой - Failover (или HA) Active/Passive, который штатно
представляет собой два узла, один из которых по факту "не работает", и
начинает работать только при сбое другого узла.
И один диск для такого кластера - тоже вполне штатное и нормальное
решение. Например:
http://en.wikipedia.org/wiki/High-availability_cluster
Именно вариант Active/Passive приведен по той ссылке.
Другие варианты кластера - да, для IB/FB отсутствуют.
Так что когда люди говорят "хочу кластер для FB", они
должны объяснять, какого типа кластер они именно хотят -
High Availability (Failover) - какого типа,
или Load Balancing.
Dmitri Kuzmenko
Vlad Khorsun wrote:
>> ок, убил.
>
> Дык не надо быть даже рядом с fb-team, чтобы на основании имеющихся и
> легко собираемых исходников сделать такие бинарники.
я все время забываю, что даже если никто не компилирует "свои ФБ", то
исходники открыты, и это можно сделать.
Dmitri Kuzmenko
Yurij wrote:
>>Попутно вопрос - что для Вас "статус", и как его сделать "известным"?
> Статус - это когда у ИТ-служб не будет возникать тупых вопросов("а
> что это такое", "а почему не Oracle", "PostgreSQL лучше") при
> упоминании что проект использует Firebird.
такой вопрос будет возникать всегда. Потому как ИТ-службы обычно
привычны к чему-то. Та же ИТ-служба, привыкшая к ФБ, аналогично
ответит и про Оракл и про PostgreSQL.
Собственно, я у Матулинского спрашивал, про статус. А то
как-то странно получается - вроде как в "здравом уме никто
с ФБ" не связывается, а тем не менее он везде, причем
именно в больших конторах.
Kovalenko Dmitry
> >> поправит) ничего.
> KD> А я тут при чем?
>
> Имелся ввиду твой тезка, который киевский Дима Коваленко :)
Аааа, дык не путай комбинацию (имя, фамилия) :-)
Коваленко Дмитрий.
www.ibprovider.com
Khorsun Vlad
>
> Hello, Vlad!
>
> Vlad Khorsun wrote:
>
>>> ок, убил.
>>
>> Дык не надо быть даже рядом с fb-team, чтобы на основании имеющихся и
>> легко собираемых исходников сделать такие бинарники.
>
> я все время забываю, что даже если никто не компилирует "свои ФБ", то
> исходники открыты, и это можно сделать.
Ага, и я тебе это всё время напоминаю :)
--
Хорсун Влад
Yurij
On May 25, 10:57 am, Dmitri Kuzmenko <k...@ibase.ru> wrote:
> > Статус - это когда у ИТ-служб не будет возникать тупых вопросов("а
> > что это такое", "а почему не Oracle", "PostgreSQL лучше") при
> > упоминании что проект использует Firebird.
> такой вопрос будет возникать всегда. Потому как ИТ-службы обычно
> привычны к чему-то. Та же ИТ-служба, привыкшая к ФБ, аналогично
> ответит и про Оракл и про PostgreSQL.
Про оракл вопросы могут возникнуть только насчет "где взять деньги на
него". Из попадающихся под руки СУБД нездоровая реакция у ИТ-служб,
админов и прочего персонала возникает только насчет FB(подозреваю, что
и IB тоже, если использовать его). Я считаю, что это связано с
недостаточным пиаром проекта.
Тяжкое наследие Борланда, который сдох по этой же причине - идеальные
технические решения, и полный мрак в плане маркетинга. Будет нехорошо,
если FB последует той же дорогой.
Yurij
On May 21, 3:56 pm, Alexey Kovyazin <alexey.kovya...@gmail.com> wrote:
> Всем привет,
>
> В процессе размышлений о судьбах вселенной, пришла ко мне мысль о том,
> что реальные проблемы в Firebird вообще отсутствуют.
> Ну то есть технические проблемы такого рода, которые напрягали бы
> разработчика или админа в процессе разработки и эксплуатации.
> Вот.
> Прошу опровергнуть мое мнение и написать если не три, то хотя бы две
> насущные проблемы в Firebird.
А вот кому свежей насущной проблемы?
Я то знаю, что проблема скорее у меня, чем с FB, но в некотором роде в
FB не помешало бы сделать затычку от такого.
Делаем регламентный backup-restore. В базе есть таблица около 50 млн
записей. На компе юзера загадили диск C, и при попытке ресторе оное
падает при активации индексов. Про то, что это проблема именно с
временными файлами сортировки, я вспомнил только со второ
Khorsun Vlad
> Про то, что это проблема именно с
> временными файлами сортировки, я вспомнил только со второ
Да, проблема с временными файлами имеет место не только
на сервере и не только у ФБ :-D
--
Хорсун Влад
Yurij
(...черви заставили послать сообщение посередине..)
только со второй попытки. В логах сервера пусто.
Может в сообщения об ошибках выводить более подробно информацию, на
каком файле и при какой операции не хватило места?
И таки писать больше информации в лог сервера, а то там ничего, кроме
ошибок обрыва сетевых соединений, и нету в большинстве случаев.
Yurij
Я прямо сейчас это дело прямо там исправляю, активирую индексы после
не прошедшего рестора. Хорошо, хоть на звонки злых пользователей
отвечает специально назначенная девушка.
Khorsun Vlad
>> А вот кому свежей насущной проблемы?
>> Я то знаю, что проблема скорее у меня, чем с FB, но в некотором роде в
>> FB не помешало бы сделать затычку от такого.
>>
>> Делаем регламентный backup-restore. В базе есть таблица около 50 млн
>> записей. На компе юзера загадили диск C, и при попытке ресторе оное
>> падает при активации индексов.
Падает ? Али ошибку отдаёт ?
>> Про то, что это проблема именно с
>> временными файлами сортировки, я вспомнил только со второ
> (...черви заставили послать сообщение посередине..)
>
> только со второй попытки. В логах сервера пусто.
>
> Может в сообщения об ошибках выводить более подробно информацию, на
> каком файле и при какой операции не хватило места?
А разве это не так ?
--
Хорсун Влад
Yurij
On May 25, 5:09 pm, "Khorsun Vlad" <hv...@optima.com.ua> wrote:
> "Yurij" ...
> Падает ? Али ошибку отдаёт ?
Ошибка только о том, что нету места. Где именно нету - не написано.
> > только со второй попытки. В логах сервера пусто.
> > Может в сообщения об ошибках выводить более подробно информацию, на
> > каком файле и при какой операции не хватило места?
> А разве это не так ?
Statement failed, SQLCODE = -902
operating system directive WriteFile failed
-Недостаточно места на диске.
After line 21 in file activate.sql
Khorsun Vlad
>
>
>> "Yurij" ...
>> Падает ? Али ошибку отдаёт ?
> Ошибка только о том, что нету места. Где именно нету - не написано.
От не нада тогда говорить что падает, не нада.
>> > только со второй попытки. В логах сервера пусто.
>> > Может в сообщения об ошибках выводить более подробно информацию, на
>> > каком файле и при какой операции не хватило места?
>> А разве это не так ?
>
> Statement failed, SQLCODE = -902
> operating system directive WriteFile failed
> -Недостаточно места на диске.
Мда, для временных файлов только это пишется.
В 1.5 и имя файла писалось.
В трекер.
--
Хорсун Влад