Страница 1 из 1
Универсальная справочная таблица
Добавлено: 30 авг 2007, 11:59
Spa_2002
День добрый.
В приложении используется много выпадающих списков с набором стандартных значений разных параметров. Должна быть возможность расширять набор параметров из программы.Городить для каждого такого списка отдельную таблицу мне кажется слишком расточительно. Делаю такую таблицу
Код: Выделить всё
CREATE TABLE UNISPRAV (
PAR_ID INTEGER NOT NULL,
PAR_VID VARCHAR(30) NOT NULL,
PAR_VAL VARCHAR(500) NOT NULL,
);
поле PAR_ID - PK автоинкрементное через генератор
PAR_VID - категория (вид) справочных данных
PAR_VAL - собственно справочное значение
и храню в ней данные для всех этих списков. Категории для выборки жестко зашиты в текстах запросов, но набор данных по каждой категории можно расширять. Знаю , что при этом нет однозначной ссылочной целостности в базе, т.к. если связывать через FK другие таблицы с UNISPRAV то эта связь не будет учитывать категорию.
Насколько приемлем такой способ для решения этой задачи?
Добавлено: 30 авг 2007, 12:20
Merlin
А сделать Unique (PAR_ID, PAR_VID), и референситься из таблиц на него папа не разрешает?
Добавлено: 30 авг 2007, 12:50
WildSery
Я бы ещё категории в отдельный справочник вынес. Можно прямо в эту же таблицу.
PAR_VID превратится в INT.
Добавлено: 30 авг 2007, 14:05
Dimitry Sibiryakov
А зачем ссылочной целостности учитывать категорию?
Добавлено: 30 авг 2007, 14:22
Merlin
Dimitry Sibiryakov писал(а):А зачем ссылочной целостности учитывать категорию?
Для стройности, системности и понятности
Ну и снижает вероятность ошибок типа сослать код валюты на субсправочник стран
Добавлено: 31 авг 2007, 06:52
Spa_2002
Спасибо корифеям за внимание к моей теме!
to Merlin:
чтобы референситься на Unique (PAR_ID, PAR_VID) из других таблиц, получается что надо тащить в эти таблицы по дополнительному полю (для хранения PAR_VID) на каждое справочно-зависимое поле. Тогда согласен, будет все жестко.
to WildSery
в вашем предложении вижу выгоду в возможности уменьшения размеров таблицы из-за использования поля INTEGER вместо varchar(...), т.е. название категории может быть достаточно длинным
Добавлено: 31 авг 2007, 09:54
WildSery
Ссылаться на категорию по INT, а не по строке, ведь тоже удобнее?
Добавлено: 31 авг 2007, 11:59
Spa_2002
Тоже неплохо, но с именем категории запросы читабельнее ИМХО. )
Добавлено: 31 авг 2007, 12:21
Merlin
Spa_2002 писал(а):Тоже неплохо, но с именем категории запросы читабельнее ИМХО. )
А приджойнить опять папа не разрешает? Недобрый он у тебя какой-то.
Добавлено: 31 авг 2007, 13:10
kdv
чтобы референситься на Unique
запомни - стольбцы, идентифицирующие запись, это не unique а ПЕРВИЧНЫЙ КЛЮЧ, primary key! Unique constraint - это АЛЬТЕРНАТИВНЫЙ, т.е. "второстепенный уникальный ключ". Используется например для столбцов типа "номер паспорта", которые сами по себе должны быть уникальны, но не являются ИДЕНТИФИКАТОРОМ записи.
Добавлено: 31 авг 2007, 13:36
Merlin
kdv писал(а): чтобы референситься на Unique
запомни - стольбцы, идентифицирующие запись, это не unique а ПЕРВИЧНЫЙ КЛЮЧ, primary key! Unique constraint - это АЛЬТЕРНАТИВНЫЙ, т.е. "второстепенный уникальный ключ". Используется например для столбцов типа "номер паспорта", которые сами по себе должны быть уникальны, но не являются ИДЕНТИФИКАТОРОМ записи.
И ты запомни - референситься на него можно и иногда нужно
Добавлено: 02 сен 2007, 20:51
kdv
И ты запомни - референситься на него можно и иногда нужно
я-то в курсе. просто unique обычно лепят вместо ПК. Есть или тулзы такие, или люди.
Добавлено: 03 сен 2007, 05:52
Spa_2002
Ну, от PK мы тоже не отказываемся, это же святое...
поле PAR_ID - PK автоинкрементное через генератор
Добавлено: 03 сен 2007, 09:14
kdv
не все автоинкрементные столбцы являются первичными ключами