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

[metaclass]

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

Comments

[nekhill.livejournal.com]

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

[vp.livejournal.com]

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

[nekhill.livejournal.com]

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

[nekhill.livejournal.com]

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

[metaclass.livejournal.com]

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

[nekhill.livejournal.com]

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