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

Создаем три таблицы. Trees - дерево справочника. Используя его можно вывести справочник в упорядоченном виде, при этом одно наименование может находиться в разных ветвях дерева не меняя свой идентификатор (это пояснение для тех, кто захочет расположить наименование в дереве :). В таблице Names находятся все наши значения, как для дерева, так и для параметров. Таблица Params - вспомогательная, предназначена для хранения каких либо поясняющих значений, кратких наименований и прочей вспомогательной лабуды.

Create table Trees
(Tree_ID number
Owner_ID number
Name_ID number)

Create table Names
(Name_ID number
Name_Val <char type>)

Create table Params
(Owner_ID number
Par_Name_ID number
Name_ID number)

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

select T.Owner_ID, T.Tree_ID, T.Name_ID,
(select N.Name_Val from Names N
where N.Name_ID=T.Name_ID) "Name",
Level
from Trees T
start with T.Owner_ID is Null
connect by prior T.Tree_ID=T.Owner_ID

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

Ввод нового наименования осуществляется через хранимую процедуру (точнее функцию, возвращающую идентификатор).

CREATE OR REPLACE
function InsertName(
in_NewName in string) return integer
AS
ret_ID integer;
begin
select Name_ID into ret_ID
from Names
where Name_Val=in_NewName;
return ret_ID;
exception
when No_Data_Found then
select <Seq>.NextVal into ret_ID from Dual;
insert into Names values (ret_ID, in_NewName);
return ret_ID;
when Others then
<Ваши действия>
end;

Таким образом при вводе не надо искать какое либо наименование (или параметр), он будет выбираться автоматически, если существует конечно. Для быстрого поиска лучше сделать bitmap index.

Использовать хранимую информацию можно двумя способами: по идентификатору наименования - когда нас интересует только само наименование, или по идентификатору дерева - когда нас интересует раздел, в котором находится это наименование. В общем - широкое поле для творчества :)

Удачи.

funikovyuri

ЗАЧЕМ???

Хороший вопрос :)

1. При наличии большого количества справочных таблиц с малым количеством строк будут быстрее отрабатываться запросы, если нам нужно использовать сразу несколько справочных таблиц, поскольку уменьшается количество считываемых блоков.
2. Уменьшается количество ХП для управления справочниками.
3. Для нового справочника не надо делать новую таблицу, ХП, клиентскую часть и т.п. (в том случае, если справочник укладывается в данную концепцию). Достаточно создать еще одну ветвь.
4. Удобный поиск по контексту наименования, поскольку искать надо не по десятку таблиц, а (всего лишь!!!) по одной, хотя и большой.

Можно еще предложить много вкусностей. Пока я слышал немного аргументов против такого справочника. Может кто выскажет?

funikovyuri

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

Какие данные используете для прогноза? Я упоминал - это СУБД Oracle. Справочник не претендует (в приведенном виде) на универсальность, но поможет объединить все однотипные данные, что в основном и требуется автору вопроса.

2. Уменьшается количество ХП для управления справочниками.
Если получились одинаковые SP - то это один и тотже справочник

Они не одинаковые. Там одна ХП на весь справочник. Конечно свои ХП для удаления и обновления.

б) как реализовать повторное использование кода справочника(или любого другого)

Не понял вопроса - какого кода? SP? DDL? И зачем его использовать?

Обычно это наследование + generic programming + ...
Наследование в БД - процесс исследованный
generic programming - в БД нет - это задача для CASE но лично я как это сделать пока представляю слабо
Т.е. что бы я хотел видеть в CASE - возможность использования одной модели как шаблона для другой при этом с поддержанием обратной связи :)

Сразу чувствуется ООП. А нафига? Все решается простыми методами, без лишних наворотов. Один раз создаются таблицы, процедуры, функции и работает без изменений. С ООП лучше заниматься написанием игр и прочей лабуды, а к базам нужно подходить со стороны SQL. Да и мыслить надо не категориями программирования а, скорее, абстрактно, как художник :)

2 funikovyuri

Не понял вопроса - какого кода? SP? DDL? И зачем его использовать? - и его тоже! Основная цель большинства современных методологий программирования обеспечить повторное использование кода!

Вопрос понятен. Что мешает использовать приведенный мною справочник в системах ERP, CRM, etc.? Что это, как не переносимость кода?

Сразу чувствуется ООП. А нафига? Все решается простыми методами, без лишних наворотов.
К сожаление данные методы хорошо накатаны только у кроликов.

Под кроликами ты понимаешь тех, кто проектирует базы данных?

С ООП лучше заниматься написанием игр и прочей лабуды, а к базам нужно подходить со стороны SQL. Да и мыслить надо не категориями программирования а, скорее, абстрактно, как художник :)
По крайней мере очень безответсвенное высказывание

Опять, двадцать пять :( Яснее можно изъясняться?

Если ты имеешь в виду подход "как художник" , то могу пояснить: проектировщик должен сразу видеть как будет работать его система, в каком направлении будет развитие. То бишь видеть картину целиком :)

А если про ООП, то могу предложить показать справочник, написанный полностью на ООП. Чтобы он мог предоставлять до 1000000 наименований.

Теоретический трындеж хорош, но заказчики требуют практических результатов :)

2 Серега

Господа. А вы считаете, что описанная в топике таблица -
справочник?

Нет :) По этой причине и предложил свой вариант решения.

А найти "универсальный" способ организации данных - тут попахивает "универсальной" базой данных - утопия ИМХО, как "универсальный" размер ботинок.

Золотые слова. Универсального и идеального в природе не существует. Моя схема может применяться во многих (но не во всех!!!) случаях и ее использование дело каждого индивидуума :)