Организация структуры БД

← →
alsov © (2007-02-07 10:19) [0]

Приветствую, Мастера

Имеется следующий вопрос

Есть две таблички
1 - Параметр
2 - Тип параметра
3 - Значение параметра
4 - Набор справочников (допустим справочник 1, справочник 2 и т.д.)

Значение параметра может быть и строкой, и числом, и датой, и ссылкой на справочник.

Вопрос: Как сохранить эту радость в бд.

Есть 2 варианта:

1. Для каждого типа параметра сделать свою табличку, т.е. будут следующие таблички
- Строчное значение параметра, всязано идентифицирующей всязью с таблицей Значение
параметра (аналогично для даты и числа)
- Связка многие ко многим Значения параметра и каждого справочника. За то, из какого
справочника брать данные отвечает тип параметра.

Минусы:
- Много таблиц наплодиться

Плюсы:
- Ограничение целостности базы сохраняется

2. Значение параметра храниться в таблице Значение параметра как строка (и число, и дата,
и ссылка на справочники). Тип значение в приложении определяется по типу параметра. Т.е.
для ссылки в значении храниться ид значения справочника, а по типу парамтра определяется
из какого именно справочника брать данные для связки

Минусы:
- Целостность базы поддерживается на уровне приложения

Плюсы
- Нету кучи таблиц связки.

Какой из вариантов лучше? Или же есть какие-ниудь другие варианты?

Заранее спасибо за любую помощь.

← →
Сергей М. © (2007-02-07 10:42) [1]

СУБД какая ?

← →
фдыщм (2007-02-07 10:53) [2]

Оракл

← →
alsov © (2007-02-07 10:53) [3]

Оракл

← →
evvcom © (2007-02-07 11:02) [4]

> [0] alsov © (07.02.07 10:19)
> Минусы:
> - Целостность базы поддерживается на уровне приложения

Ну почему ж? Целостность можно поддержать триггерами и пакетами.

← →
Desdechado © (2007-02-07 11:17) [5]

> Есть две таблички
А описал одну.

> Минусы: Много таблиц наплодиться
Не вижу много, всего 4 (при одном справочнике), т.к.
> Значение параметра может быть и строкой, и числом, и датой, и ссылкой на справочник.

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

> Целостность можно поддержать триггерами и пакетами.
Стремно очень.

← →
Sergey13 © (2007-02-07 11:17) [6]

На
http://www.sql.ru/forum/actualtopics.aspx?bid=36
это достаточно часто обсуждается.

> Есть две таблички
> 1 - Параметр
> 2 - Тип параметра
> 3 - Значение параметра
> 4 - Набор справочников (допустим справочник 1, справочник
> 2 и т.д.)

Если честно, то я немного не въехал в желаемую структуру. Например параметр - он же чего-то там параметр, а не сам по себе параметр. Нутром чую, что это про неопределенное количество параметров, но к описанию применить не могу. 8-)

← →
alsov © (2007-02-07 11:28) [7]

Desdechado

> > Есть две табличкиА описал одну.

Очепятался

> Если же справочники есть возможность свести в одну таблицу,
> добавив поле "тип справочника", то все еще упрощается.
> Я за несколько таблиц и уменьшение геморроя с контролем
> целостности.

Не получается :(
У каждого справочника своя специфика.

Sergey13

> Если честно, то я немного не въехал в желаемую структуру.
> Например параметр - он же чего-то там параметр, а не сам
> по себе параметр. Нутром чую, что это про неопределенное
> количество параметров, но к описанию применить не могу.
> 8-)

Забыл описать что параметры имеют иерархическую структуру. Значения сохраняются только для чаилдов.

← →
Sergey13 © (2007-02-07 11:40) [8]

> [7] alsov © (07.02.07 11:28)

Ну я предполагаю, что есть некий объект, неопределенное количество параметов надо хранить. Так? Наверное сначала надо определиться как хранить собственно список параметров этого объекта. А потом уже думать над хранением их значений. Может быть ограниченное значение параметров вообще (без привязки к объекту, т.е. справочник параметров), а может быть произвольный набор произвольных параметров (типа захотел полосатость в джоулях добавить - добавил для какого-то экземпляра объекта).
Пока, лично мне, задача не ясна.

← →
alsov © (2007-02-07 12:03) [9]

Есть некий набор параметров
+ тип1
--- Пар 1
--- Пар 2
+ тип2
+ подтип1
-- пар1
-- пар2

Нужно сохранять значения (которое может быть любого типа, в т.ч. ссылка на сложный справочник)

← →
Сергей М. © (2007-02-07 12:25) [10]

> alsov © (07.02.07 12:03) [9]

> любого типа

Сначала определись с предельным размером данных, требуемых для хранения значений любого типа.

← →
alsov © (2007-02-07 12:26) [11]

Тип может быть либо строка, либо целое число, либо дата, либо ссылка на справочник.

Наполнение базы пока неизвестно. Структура должна быть как можно более универсальна

← →
Сергей М. © (2007-02-07 12:34) [12]

> alsov © (07.02.07 12:26) [11]

Я про размер спрашиваю, а не про тип. Разницу-то ощущаешь между типом и размером ?

← →
evvcom © (2007-02-07 12:56) [13]

> [5] Desdechado © (07.02.07 11:17)
> А описал одну

А я подумал, что 4. Там цифры от 1 до 4 :)

> > Целостность можно поддержать триггерами и пакетами.
> Стремно очень.

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

← →
alsov © (2007-02-07 15:28) [14]

Сергей М.

Размер пока неизвестен. Параметров скорей всего будет около 100-200, будет порядка 1000 обследований, которые будут содержать по 10-30 значений параметров.
Но это не окончательно.

evvcom

> Я только написал, что это можно. А стремным я б назвал описание
> задачи и, возможно, принятую (принимаемую) структуру. А
> чтобы что-то предложить, мало информации.

Какой именно информации нехватает? Объема данных.
Просто это только часть структуры. Хотелось определиться какой из названых подходов лучше.

← →
Sergey13 © (2007-02-07 15:33) [15]

> [14] alsov © (07.02.07 15:28)

Наверное будет проще разговаривать, если расскажешь про предметную область твоей задачи.

← →
alsov © (2007-02-07 15:42) [16]

Если в двух словах то так
Есть некие Обследования, по результатам которых к некоему Объекту привязывают Значения Парметров. Параметры в свою очередь могут быть разнотипными, в том числе и ссылаться на некие справочники (например Технологическая система, Группа безопасности и т.д.)

← →
Сергей М. © (2007-02-07 15:57) [17]

> Размер пока неизвестен

Вот как только будет известен, тогда и приходи.

← →
Danilka © (2007-02-07 16:14) [18]

1. Какие операции над значениями параметров будут производится в БД?
2. Поищи в ентернете статью Анатолия Тенцера "БД - хранилище объектов". Там подробно рассматривается то, о чем ты спрашиваешь, пример реализации, плюсы, минусы.

← →
evvcom © (2007-02-07 16:28) [19]

> [14] alsov © (07.02.07 15:28)
> Какой именно информации нехватает?

Вот этой:

> [15] Sergey13 © (07.02.07 15:33)
> если расскажешь про предметную область твоей задачи

а твой ответ

> [16] alsov © (07.02.07 15:42)
> Есть некие Обследования, по результатам которых к некоему
> Объекту привязывают Значения Парметров

не менее абстрактен, чем [0]. Нафига привязывать еще и некие параметры к некоему объекту? Ты нам втуляешь, что тебе надо что-то, что ты сам решил, может совсем и неверно решил. Если нужна помощь, расскажи внятно исходную задачу, а не басню про некие засекреченные объекты.

← →
alsov © (2007-02-07 16:53) [20]

evvcom ©
> не менее абстрактен, чем [0]. Нафига привязывать еще и некие
> параметры к некоему объекту? Ты нам втуляешь, что тебе надо
> что-то, что ты сам решил, может совсем и неверно решил.
> Если нужна помощь, расскажи внятно исходную задачу, а не
> басню про некие засекреченные объекты.

Я б с удовольствием рассказал, но это и мне пока неизвестно. Если б было все понятно стал бы я спрашивать. Я просто колеблюсь между двумя вариантами хранения данных.

Danilka © [18]
> 1. Какие операции над значениями параметров будут производится
> в БД?2. Поищи в ентернете статью Анатолия Тенцера "БД -
> хранилище объектов". Там подробно рассматривается то, о
> чем ты спрашиваешь, пример реализации, плюсы, минусы.

Спасибо поищу

← →
Sergey13 © (2007-02-07 16:55) [21]

> [20] alsov © (07.02.07 16:53)

Советую тогда дождаться нормального ТЗ. Тема на самом деле достаточно сложная и интересная, но как всегда все упирается в детали.

← →
Сергей М. © (2007-02-07 16:56) [22]

> колеблюсь между двумя вариантами хранения данных

Это какими же, позвольте осведомиться ?

← →
alsov © (2007-02-07 17:09) [23]

Sergey13 [21]
> Советую тогда дождаться
> нормального ТЗ. Тема на самом деле достаточно сложная и
> интересная, но как всегда все упирается в детали.

Ясно

> Сергей М. © (07.02.07 16:56) [22]
> > колеблюсь между двумя вариантами хранения данныхЭто какими
> же, позвольте осведомиться ?

Те, которые описаны в вопросе

← →
ANB © (2007-02-07 17:20) [24]

Текс.
Значится по строкам, датам и числам на выбор - все в одно строковое поле или типизировать, а потом вытаскивать нужное значение в зависимости от типа параметра.
Как прикрутить нужный набор параметров к какому то объекту - тоже понятно - ссылкой на объект.

Самое интересное - значение параметра, как ссылка на другой объект / справочник, да еще и с сохранением ссылочной целостности (запрет ссылок на несуществующий объект, запрет удаления объекта, если на него есть ссылка).
Тут, имхо, можно без триггеров (на честных FK) выкрутиться, только если вести стержневую таблицу, содержащую все объекты.
Есно, ID этой таблицы должен крутиться одним сиквенсом => у каждого объекта/элемента справочника в БД будет уникальный ID. Я уже видел систему, построенную по такому принципу - в принципе идея интересная.
А вот тонкую подкрутку типа такой тип параметра должен ссылаться тока на тот или другой справочник - это тока триггером разрулить мона (правда, его можно сделать довольно универсальным).

[24] ANB © (07.02.07 17:20)
> в принципе идея интересная

Если тема интересная, то тоже поищи статью Тенцера. :)
Там еще рассматриваются исторические типы данных, связи объектов, еще что-то, количественный и суммовой учет, вобщем много всего.
Интересная статья.

уровень геморроя при выборке из такой структуры надо б ОЧЕНЬ хорошо продумать ДО ТОГО

> Те, которые описаны в вопросе

А почему только два варианта ? И почему для 2-го варианта именно в строке ? А если завтра потребуется хранить данные типа медиа (картинки, видео, саунд и т.п.) ?

> [24] ANB © (07.02.07 17:20)
> все в одно строковое поле или типизировать, а потом вытаскивать
> нужное значение в зависимости от типа параметра.

Имхо, лучше типизировать. Null значение каши не просит (ну места в смысле), так что потери на этом не будет. А в случае надобности, описанной [28], добавляется дополнительное поле, правится check constraint на допустимое значение поля типа данных и чуток запрос. Переделок минимум.

Типичная ошибка новичка - не определена однозначно ни предметная область, ни инфопотоки, ни характеристики сущностей, а сразу строим "таблицы", "индексы", "справочники"..

И типична же реакция форума - никто не понял задачи, но хором советуют триггеры, хранимки, связи и, как венец мироздания - уракакл как панацея от всех болячек ;))

Petr V. Abramov

Вот и думаю :)

Сергей М.

Для медиа данных есть отдельный реестр.

evvcom

Имеете в виду для каждого типа значений свое поле или же отдельная связаная табличка?

MsGuns

В том то и дело что толкового описания что будет храниться в базе еще нет. Все что мне известно я описал в посте [16]

>alsov © (08.02.07 09:23) [31]
>В том то и дело что толкового описания что будет храниться в базе еще нет. Все что мне известно я описал в посте [16]

Тогда вся эта ветка - просто пустой треп

> [30] MsGuns © (08.02.07 09:07)
> никто не понял задачи

Тут ты прав.

> но хором советуют триггеры, хранимки, связи

Это где ты хор увидел?

> и, как венец мироздания - уракакл как панацея от всех болячек

Во-первых, почему "какл"? Тебя бесит, что ты его не знаешь?
А во-вторых, автор сам заявил, что он делает на оракле.

Если использовать сервер как Хранилище,всю работы взвалив на клиента, то вариант - 2

Если же хочется прозрачного видения предметной области, то "Много таблиц наплодится" - это не минус, а ПЛЮС, ибо каждая таблица - это вычлененные сущ ности и их связи.
Для пердметной области "Слад всякой всячины", где всего-то и нужно, что найти что-то по имени или по значению произвольгого атрибута длстаточно таблиц из варианта [2]

Организация структуры БД Найти похожие ветки