Схема базы данных SQL с минимальным количеством таблиц — различия между версиями
Chegeware (обсуждение | вклад) (→Подход 1) |
Chegeware (обсуждение | вклад) (→Типовая структура таблицы значений) |
||
| Строка 16: | Строка 16: | ||
В таблице объекта в ячейке свойства вместо самого значения будет храниться идентификатор-ссылка, являющийся первичным ключом для совокупности записей в специальной таблице значений. Для каждого типа данных создается отдельная таблица значений. | В таблице объекта в ячейке свойства вместо самого значения будет храниться идентификатор-ссылка, являющийся первичным ключом для совокупности записей в специальной таблице значений. Для каждого типа данных создается отдельная таблица значений. | ||
====Типовая структура таблицы значений==== | ====Типовая структура таблицы значений==== | ||
| − | * "ид" integer not null primary key, значение берется из генеральной последовательности | + | * "ид", integer, not null, primary key, значение берется из генеральной последовательности |
| − | * "ид1" integer not null, ссылка на таблицы/колонки объектов | + | * "ид1", integer, not null, ссылка на таблицы/колонки объектов |
| − | * "значение" нужный тип данных, непосредственное значение | + | * "значение", нужный тип данных, непосредственное значение |
Версия 10:05, 14 сентября 2010
Основная предпосылка
Обычно в схеме базы данных (БД) предусматривается отдельные таблицы для каждого объекта/сущности/явления. Название таблицы адекватно названию объекта. Кроме того часто вводятся дополнительные вспомогательные и подчиненные таблицы. Количество таблиц вырастает до больших количеств. Таблицы представляет совокупность свойств/атрибутов сущностей. Для сложных объектов число колонок/полей вырастает до больших количеств. Подчиненные таблицы часто вводятся в случае множественности значений определенных свойств.
Некоторые серверы СУБД предлагают массивовые типы данных (ARRAY), для которых в одной ячейке можно сохранять массив значений.
В описываемой схеме организации БД принимается необходимость хранения каждого значения каждого свойства каждого объекта в виде отдельной записи. К чему приводит данная предпосылка рассказано в тексте данной статьи.
Постулат 1
Все таблицы в этой схеме обязательно имеют одну колонку/поле - целочисленный идентификатор (сокращенно ИД), являющийся первичным ключом (PRIMARY KEY). Все идентификаторы генерируются из одной последовательности, т.е. сколько бы ни было таблиц в схеме нет ни одной записи с одинаковыми идентификаторами.
Понимание этого постулата возможно после дальнейшего изучения данной статьи. Генерация единой последовательности возможна как средствами самого сервера СУБД (например, sequence у PostgreSQL), так и привлечением специальных средств языков программирования или даже создание/использование специального сервера/сервиса.
Подход 1
В таблице объекта в ячейке свойства вместо самого значения будет храниться идентификатор-ссылка, являющийся первичным ключом для совокупности записей в специальной таблице значений. Для каждого типа данных создается отдельная таблица значений.
Типовая структура таблицы значений
- "ид", integer, not null, primary key, значение берется из генеральной последовательности
- "ид1", integer, not null, ссылка на таблицы/колонки объектов
- "значение", нужный тип данных, непосредственное значение
