Простой вопрос о простых базах

[vg]

В той конторе, где я работаю, часть баз данных – «навязана сверху». Мы не имеем права что-либо менять в их структуре. Вернее в «отчётных форматах». Вопрос о том, что можно посоветовать разработчикам «локализованных» версий, что бы избавиться от хм. гм-гм (см. ниже) ?

Одна из особенностей тех баз в том, что практически все «справочники» представляют отдельные таблицы. На каждую сущность – своя таблица. Например, территориальные районы – отдельная таблица, города – другая таблица, и т.д. Таким образом, в базе присутствует порядка 90-100 различных «справочных» таблиц (число варьирует от релиза к релизу).
Практически все таблицы имеют одинаковую структуру типа, id, textval, code1, code2.
Заполнение – мизерное 10-100 записей на таблицу. Интенсивность изменений – почти нулевая. Очень редко оператор добавляет новые данные в справочники.

Что думают отцы-архитекторы?

[папа Карло]

все нормалньо. ничего не трогай.

[vg]

Ну, почему, Папа?
Почему, почему, почему???

Объясни. Почему мы должны расхлёбывать постоянно, то, что творят Московские недоархитекторы, недопрограммеры и ещё много чего недо-?

Неужели нельзя было проанализировать, что и насколько интенсивно будет юзаться. Неужели нельзя было "сгруппировать" сии сущности, объединив их в несколько таблиц. Но не 100 же?

Для различения последних (когда это необходимо, конечно) в клиетской проге - ввели бы дополнительное поле, где кодировалась бы сама "сущность". Т.е. район - code == 1, город - code == 2 и т.д.

Не понимаю. Хоть убей.

[папа Карло]

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

[vg]

Хорошо. Пусть живут.
Но мне бы хотелось выяснить некоторые детали по существу, в том числе, и в части целостности.

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

1) индекс для поля id
2) индекс для поля textval
3) индекс или индексы, гарантирующие уникальность id
4) индекс для защиты целостности ссылок по id

Итого на 100 таблиц 500 объектов

Если делать "группировку",
пусть в 20 таблиц с близкими понятиями (полезные ископаемые - к полезным, вся география к геогррафии и т.д. в простейшем случае)

1) Для всех таблиц - 100 индексов для защиты целостности ссылок
2) 20 индексо для поля id
3) 20 индексов для поля textval
4) 20 индексов для поля code

Итого на "справочную часть" имеем 180 объектов. И всё не хуже защищено. Надёжность и эффективность - выигрывают. Чем меньше объектов - тем лучше.

Кроме того есть подозрение и в части повышения "быстродействия" из-за страничной организации памяти приработе с таблицами MS SQL Server.

Давай аргументы. Аргументы давай.

[Lena]

Давай аргументы. Аргументы давай.

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

[MarkM]

Что тебя волнует. Все сделано правильно с точки зрения 3-й НФ.
СУБД почти пофиг, будет там 500 объектов или 50.
Главное чтоб людям удобно было.
Такой дизайн очень гибок.
Если надо изменить одну таблицу, то это не повлияет на другие части приложения.
Если брать МС СКЛ, то вероятность дэдлоков уменьшается.

А вообще можно написать систему и на ОДНОЙ таблице с 3-5-мя полями,
ID,PARENTID,TYPEID,VALUE

[папа Карло]

Если брать МС СКЛ, то вероятность дэдлоков уменьшается.

локов, а не дедлоков.

[vg]

2All,
Спасибо за реакцию. Все высказались верно.
Благодарности MarkM. Конечно, ты прав.

Ладно, нэхай цэ живэ у Москалей.

[vg]

Да и ещё, братцы.

Постараюсь исправить свою натуру на букву "г" (у меня это из фамилиё). Вечно мне надо к чему-то придраться.
Думаю, или это я не опохмелился, когда задавал вопрос. Не помню.

Вообще, конечно, прошу прощения за мой глуповатый топик.

[Marmot]

Да и ещё, братцы.

Постараюсь исправить свою натуру на букву "г" (у меня это из фамилиё). Вечно мне надо к чему-то придраться.
Думаю, или это я не опохмелился, когда задавал вопрос. Не помню.

Вообще, конечно, прошу прощения за мой глуповатый топик.

Лучше задать дурацкий вопрос, чем по дурацки сделать что нибудь....