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

[metaclass]

Софт1: написан почти целиком мной, заказной: 186 таблиц, 169 хранимых процедур
Софт2: написан мной и ребе белнетмоном, коробочный: 74 таблицы, 40 хранимых процедур

Comments

[(Anonymous)]

Соответственно, при добавлении еще одного рэбе количество таблиц и процедур еще более сократится?

[bigfrogg.livejournal.com]

>>Софт2: написан мной и ребе белнетмоном, коробочный: 74 таблицы, 40 хранимых процедур

Из которых ребе метакласс написал 90 таблиц и 62 хранимые процедуры :)

[metaclass.livejournal.com]

Сложный вопрос. Возможно, увеличится, т.к. у каждого ребе будет свой кодогенератор, создающий over 9000 таблиц, вьюшек и хранимых процедур за один вызов :)

[metaclass.livejournal.com]

Не, у нас разделение труда другое - ребе белнетмон пишет код, а я потом код удаляю :)
Я не умею писать код, а ребе религия запрещает его удалять.

[zelanton.livejournal.com]

Ребе, мы в вас верим, число таблиц и процедур непременно превысит цифру 1000!

[metaclass.livejournal.com]

Не, я столько даже в модели для кодогенератора заполнять задолбусь. Не говоря уже о том, что клиенты столько сущностей не придумают. А если придумают - то все равно там большая часть сведется к одной таблице типа "Documents(ID,blob)" :)

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

[komarov.livejournal.com]

НАХЕРА СТОЛЬКО?!?!?!

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

[metaclass.livejournal.com]

"Так получилось".

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

[dmzlj.livejournal.com]

действительно. доказано ведь, что для каждой задачи заведомо достаточно трех таблиц.

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

[metaclass.livejournal.com]

Entities,Attributes,Values?

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

[dmzlj.livejournal.com]

Ну можно и так. Вообще-то число могло быть любым, это типа была ирония.

одна

[sa-chernomor.livejournal.com]

create table universe (
id,
parent,
type := entity|attribute|value,
blob
)

Re: одна

[dmzlj.livejournal.com]

поля id, parent и type --- лишние.

Re: одна

[volodymir-k.livejournal.com]

Потому что запись в этой таблице будет одна. В ней будет храниться зазипованная БД фокспро с сотней таблиц.

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

[g-rub.livejournal.com]

... (вкрадчиво) ребе, а Вы еще не использовали RDF в проектировании моделей предметной области? Там как раз три типа сущностей: субъекты, объекты, предикаты...

(удалился, злорадно похихикивая)

[ilya-portnov.livejournal.com]

В нашей софтине есть такая специальная концепция, 'публикация отчётов'. Типа, кнопочки для вызова разных отчётов должны появляться в разных местах, и это должно очень гибко конфигуряться. Для этого наворочен десяток сущностей с замысловатыми отношениями. Когда я спросил товарища, который формально за это в команде отвечает, нафига так сложно, ответ был: 'я три раза вносил предложения сделать проще. Предложения приняли, но в итоге каждый раз становилось сложнее'.

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

[metaclass.livejournal.com]

Мне пока ER-моделей хватает.

[plumqqz.livejournal.com]

Э... А где потрясаться.

PS Что-то процедур маловато. На клиента логику тянете, лодыри...

[metaclass.livejournal.com]

Логика в базе очень сильно усложняет обновление - в Firebird нет механизма "поменить зависимые объекты как инвалидные и перекомпилировать". Только дропать все дерево зависимостей начиная с листьев, менять объект и создавать зависимые заново.
Ну и, при всей моей невменяемости - я СТОЛЬКО бизнес-логики в хранимых процедурах не напишу - отладки нет, курсоров кошерных нет, типов нормальных нет, временные таблицы использовать не получается - отчетные транзакции "только для чтения", а если их сделать пишущими - забытый юзерами отчет начинает мешать сборке мусора, и прочая, и прочая.
В общем, при всех достоинствах FB писать серверную логику на нем сложно.

[nekhill.livejournal.com]

Софт3: писался 5 лет, потом год доделывается нами. 120 таблиц, over 1000 хранимых процедур. Очень хотим извести количество хранимых процедур до около 400 (CRUD), но не получится, ибо местами очень дофига данных в таблицах, и нужно ускорять :)

[vp.livejournal.com]

1000? А в каком стиле хранимые процедуры? Может толпа чего-то мелкого?

[metaclass.livejournal.com]

Ускорять в плане - обработку делать на сервере, поближе к данным?

[nekhill.livejournal.com]

Да, мелкого полно.
Ещё есть подсистема фильтрации объектов по 100500 критериев, которая ускорения ради делается на сервере и чтобы не тащить клиенту все 300 гб базы данных. В фильтрацию мы даже не лезем - её писал уже покинувший контору человек, любящий сильно нетрадиционные подходы.
Ещё есть слабообоснованное дублирование некоторого числа ключевых сущностей ради, допустим, многоязычной сортировки на стороне сервера БД, которое тащит за собой дублирование всех взаимодействующих ХПшек.
Собственно, всё это надо активно и жестоко чистить, но есть ещё near 500 000 строк мудрёного кода, поток новых требований и 2 разработчика на всё.

[nekhill.livejournal.com]

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

[nekhill.livejournal.com]

Да, приложение сначала разрабатывали таким, чтобы оно на каждый чих сохраняло все сделанные изменения в БД. Извращенцы. Сейчас точим его в направлении "грузить объектами, держать на клиенте, периодически кидать в БД". Соответственно, в результате первого подхода был написан комплект ХП на довольно атомарные операции и на каждый чих. При этом SQL-запросы в явном виде из приложения не швыряются _никогда_.