metaclass | Адъ баз данных

Это потому что Вамъ не приходись писать софтъ в котором PDF был форматом входныхъ данныхъ.

>>отладки нет
есть в IBExpert. Однако я в основном пользуюсь аналогом showmessage только в таблицу лога.

>>курсоров кошерных нет
for select, а сейчас еще появились такие чудные штуки как select from select и execute block

>>типов нормальных нет,
нормальных - это каких?

>>временные таблицы использовать не получается - отчетные транзакции "только для чтения",
>>а если их сделать пишущими - забытый юзерами отчет начинает мешать сборке мусора,
после появления перечисленного в предыдущем пункте надобность в temp table у меня как-то отпала, но таблица времени транзакции мне казалось что должна позволять писать и в RO транзакции..

Перекомпиляция всех процедур - есть такая функция в IBExpert.
Менять тип поля иногда да, бывает сложно...

Засунув процедуру которая работает с большим кол-вом данных в хранимку можно значительно ускорить работу. Иногда - очень значительно.

Меньше таскать данных по сетке. Иногда имеет значение.

Можно давать права на процедуры но не на таблицы.

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

Контроль за рукоблудством. В процедуре можно проконтролировать вводимые данные.

И прочее, прочее, прочее...

Отсутствие SP в СУБД а равно неиспользование имеющейся возможности сделать SP как правило говорит от недостаточном владении инструментом.

1) Да, я в логи тоже пишу. Только вот упадочно оно, по сравнению с нормальными логгерами :)
2) Курсоры из запроса или хранимой процедуры в клиента вернуть можно? Типы у них с типами запросов совпадают?
3) Нормальные типы - это хотя бы чтобы полиморфные функции можно было делать, туплы объявлять, в общем, как в нормальных языках - как можно больше first class values
4) Во временные таблицы в RO не пишется - валится с исключением. Execute block маловато - я иногда хочу оптимизацию сделать типа "временный список с индексом и поиск по нему".

IBExpert меня как-то напрягает, я предпочитаю isql и скрипты.

На счет усложнения процесса обновления.
Структуру таблиц все равно менять приходится. Поменять/добавить SP - ничуть не сложнее.
Вместе с прогой высылается скрипт который производит изменения в базе.

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

Это хорошо в серверах с гуманными языками для хранимых процедур.

А вообще это модно счас делать на серверах приложений, которые или там же где СУБД или рядом по гигабитной сетке соединены. На базу никаких доступов - только веб-сервисы и тому подобное.
Вот что в этом печально, так это то, что логика выражаемая трехстрочным sql запросом в обычном языке часто вырождается в адскую хрень.

1. Я и в Delphi логгерами не пользуюсь, обычно натыкиваю ShowMessage. Пошаговым отладчиком пользуюсь иногда но радикальной помощи не получается.

2. Я в общем с трудом понимаю что такое "курсоры". В Firebird процедуры селективные, т.е. могут возвращать данные точно так же как и селект из таблицы. Может возвращать как одну строку так и много. Что такое тип запроса и с чем он должен совпадать - не понял.

3. Я пишу на Delphi и с приведенной терминологией не знаком :) Мне типов данных в Firebird хватает полностью, а запихивать какой-нибудь record или класс в базу - нереляционно.

На счет IBExpert - это ты очень зря. Я тоже начинал с isql во времена Interbase 4.2 но тогда IBExpert просто не было. Никто не заставляет юзать все его оглупляторские фишечки но удобство программирования под FB с применением IBE возрастает на порядок.
Категорически рекомендую понасиловать себя с IBExpert - это лучше всяких отладчиков.

"забытый юзерами отчет" - с какой стати он держит открытую транзакцию? Сформировался и тут же завершил.

У меня такое ощущение что нет достаточного опыта работы именно с FB.
Рискну привести несколько полезных ссылок:

http://sql.ru/forum/actualtopics.aspx?bid=2
http://ibase.ru/develop.htm
http://www.ibaseforum.ru/

Готов ответить на вопросы по Firebird - возможно чем-то помогу.
В частности про кошерность курсоров, типы.

fraks гав sibverk точка ru

Если что, у меня 200 внедрений коробочного софта на FB и оные ссылки я перечитывал неоднократно.

У меня отчеты (датасеты) работают в контексте транзакции, хотя действительно, можно ее закрывать после формирования.

В общем, ro-транзакция это было когда-то решение проблемы с застреванием OAT и затуплением FB на сборке мусора. Там в базу с десяток сервисов активно складывает данные и изредка были проблемы с этим.

Firebird - это как раз сервер с гуманным языком СП :)

>>логика выражаемая трехстрочным sql запросом в обычном языке часто вырождается в адскую хрень.

Именно поэтому такую логику удобно засовывать в SP.

Не всегда. Например, нельзя сделать полиморфную по типу записи/курсора хранимую процедуру, из-за чего приходится или руками дублировать код, или выражать требуемое на более подходящем языке а затем генерировать из него хранимые процедуры (что я как раз сейчас и делаю).

В моем софте (склад)
таблиц - 39
процедур - 99
триггеров - 58

>>Если что, у меня 200 внедрений коробочного софта на FB
>>и оные ссылки я перечитывал неоднократно.

Ну я поэтому и написал "рискну". А на sql.ru ты как зарегистрирован?

>>У меня отчеты (датасеты) работают в контексте транзакции, хотя действительно,
>>можно ее закрывать после формирования.

Это такая недоступная мне логика, порочная на мой взгляд, реализована везде - что типа открытый датасет почему-то должен держать активной транзакцию которая эти данные вытащила.
Чего ее держать - любые данные взятые с сервера по определению устаревшие, поэтому держи не держи - один фиг.
Поэтому я датасетами вообще не пользуюсь. У меня свой самопальный буфер, типа ClientDataSet тока он не датасет.

О, вспомнил, почему там открытая транзакция. Там fetch ленивый, т.е. по мере надобности, поэтому закрывать транзакций можно только когда дошло до eof.
Хотя грузить такие количества записей на клиента по любому маразм - иногда оно полезно.

>>полиморфную по типу записи/курсора хранимую процедуру

Можно примерчик а то не догоняю про что конкретно речь?

Ну реализовать виртуальную функцию, тайпкласс или еще какой-нибудь подобный тип полиморфизма.

Т.е. у нас например есть автоматизация предприятия, состоящего из десятка филиалов. Все записи в БД помечаются кодом филиала (Dept). Например есть три таблицы Clients(Dept int,...), Payments(Dept int,...), Sales(Dept int, ...). С точки зрения типизации это означает что все три сущности реализуют один и тот же интерфейс или тайпкласс Dept a where dept :: a -> int

Пользователи системы тоже относятся к филиалам, т.е. есть таблица UserDepts(user,dept) И мне нужно, чтобы пользователи видели только записи своего филиала. Сейчас это реализуется созданием для каждой из таблиц соответствующего view (или selectable хранимой процедуры) и фильтрацией в нем, причем код проверки везде дублируется типа (where exists(select 1 from UserDepts where UserDepts.user=current_user and UserDepts.dept=SomeTableName.dept))
Могут быть и более сложные условия, например чтобы пользователь видел только записи по относящемуся к нему клиенту, итд.

И вот эту копипасту было было желательно выпилить в отдельную функцию и проверять все в ней единообразно, а не дублировать.

Код проверки можно попробовать вынести с помощью EXECUTE STATEMENT - что бы собирать запрос проверки и подсовывать в него имя таблицы.

Но конечно это не объектность обычных языков программирования, да.

В моей системе пока не так много таблиц что бы подобная копипаста радикально напрягала.

А кстати можно сделать по другому сделать доп. таблицу в которой для каждой записи в подопытных таблицах завести запись. И Dept писАть только в эту таблицу. На нее сделать вьюху с ограничениями.
На подопытные таблицы сделать вьюхи с условием что exists в доп. таблице.

Конечно не факт что от этого не будет нести крышу у оптимизатора, но зато проверка в одном месте :)

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

В общем, язык SP не дотягивает даже до минимальных ООП языков, не говоря уже о функциональных.

Обычно 5-10 строчек в СП заменяет 50-150 строчек на клиенте.
Поэтому манипуляции намного лаконичнее.

SAP R/3 после настроек и прочей хрени.

39800 таблиц.
0 хранимок.

"Дайте мне распечатку схемы этой ~~херни~~БД, я буду на нее мастурбировать долгими зимними вечерами!"

после инсталляции с дисков размер базы... 70Gb.

Неплохо :)
Интересно, это целиком в голове кто-нибудь может удержать или нет?

Адъ баз данных

Re: Адъ баз данных

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Забыл, может самое главное :)

no subject

no subject

no subject

no subject