crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

3 страниц V   1 2 3 >  
Ответить в данную темуНачать новую тему
> Проектирование универсальной структуры БД
Litkevich Yuriy
  опции профиля:
сообщение 20.11.2009, 13:51
Сообщение #1


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9656
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Задался вопросом как бы так запроектировать структуру БД, чтобы её для всех задач использовать.
За основу взял такую задачу - справочник по радиоэлектронным компонентам.
Суть его такова, есть типы компонентов (конденсаторы, резисторы, ...). У каждого типа есть обязательный набор характеристик (для конденсаторв: Напряжение и ёмкость, для резисторов: сопротивление и мощьность). Также у каждого типа есть специфические характеристики, но необязательные (для конденсаторов: ТКЕ-температурный коэфициент ёмкости, для резисторов: ТКС - температурный коэфициент сопротивления).
Плюс к этому у каждого компонента может быть уникальная, важная характеристика.
Разумеется у каждого элемента есть марка (наименование)

Дерево элементов можно представить так:
|
|-конденсаторы
|    |- К50-35 16В  100мкФ ±20% (ёмкость-100мкФ, напряжение-16В, допуск по ёмкости ±20%)
|    |- К50-35 35В  2200мкФ ±20% (ёмкость-2200мкФ, напряжение-35В, допуск по ёмкости ±20%)
|-Резисторы
|    |- С2-32-1 100 ±5% (сопротивление-100 Ом, мощьность 1Вт, допуск по сопротивлению ±5%)
|    |- С2-29-0,5 1к ±0,5% (сопротивление-1 кОм, мощьность 0,5Вт, допуск по сопротивлению ±0,5%)


В интернете встречал такие термины - "сущьности" и "свойства сущьностей", вроде как такими терминами оперируют при проектировании БД.
Видимо это какой-то подход, на манер шаблонов проектирования программ.

Где-то так должен выглядеть процесс настройки заготовки БД:
Прикрепленное изображение


вот с типами и элементами вроде реализация сравнительно простая, а со свойствами не совсем понятно, т.к. тип данных может быть разный.
И ещё, хотелось бы для каждого свойства задавать, некое связанное свойство, например, для "напряжения" - еденицу измерения - "Вольты" (тип: "строка")

Может кто-нибудь подсказать, где про такие вещи почитать?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 20.11.2009, 14:55
Сообщение #2


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9656
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Немного усовершенствовал диалог настройки патрахов БД:
Прикрепленное изображение


А пользователь должен при этом получить примерно такой диалог:
Прикрепленное изображение
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
BRE
  опции профиля:
сообщение 20.11.2009, 15:23
Сообщение #3


Профессионал
*****

Группа: Участник
Сообщений: 1112
Регистрация: 6.3.2009
Из: Ростов-на-Дону
Пользователь №: 591

Спасибо сказали: 264 раз(а)




Репутация:   44  


Что почитать не подскажу.

Пока в голову пришла мысль: для каждого типа данных использовать отдельную таблицу, с полем value нужного типа.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 20.11.2009, 15:51
Сообщение #4


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9656
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Цитата(BRE @ 20.11.2009, 18:23) *
для каждого типа данных использовать отдельную таблицу, с полем value нужного типа.
я пока дальше этого тоже не ушёл.
Если кол-во типов ограничить:
* целое
* дробное
* текст
то три таблицы надо, вполне нормально
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Elfinit
  опции профиля:
сообщение 30.11.2009, 23:54
Сообщение #5


Участник
**

Группа: Участник
Сообщений: 127
Регистрация: 17.3.2009
Из: Казань
Пользователь №: 619

Спасибо сказали: 7 раз(а)




Репутация:   1  


Когда-то на прежней работе подобная задача ставилась...Тоже создавали универсальную структуру БД. было там порядка 15 служебных таблиц (для описания таблиц, полей, типов, связей...). На всё это вешалась куча триггеров, которые собственно и "раскручивали" всё это дело. Например, была таблица document, описывающая все "обычные" таблицы. Запись в неё приводило к созданию таблицы. Была таблица document_fields - тоже назначение понятно. Были таблицы для описания типов полей, которые делились на базовые и ссылочные. И самый верх всего этого - универсальное редактирование документов. Сценарий должен был сам подгружать данные о полях документа и создавать нужные элементы управления. Причём отредактировать можно было всё, что угодно - даже записи в documents и documents_fields, что приводило к соответствующим действиям...А ещё выстраивалась древовидная структура документов (не на внешних ключах, а "вообще")
Через некоторое время я задался задачей написания своего варинанта, на sql-server (а то было на postgres), но что-то отвлёкся и отошёл...
Скрипт прилагаю, глянь, если очень будет интересно)))

Прикрепленные файлы
Прикрепленный файл  common_db.zip ( 7.31 килобайт ) Кол-во скачиваний: 119
 
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Elfinit
  опции профиля:
сообщение 1.12.2009, 9:54
Сообщение #6


Участник
**

Группа: Участник
Сообщений: 127
Регистрация: 17.3.2009
Из: Казань
Пользователь №: 619

Спасибо сказали: 7 раз(а)




Репутация:   1  


Цитата(Litkevich Yuriy @ 20.11.2009, 15:51) *
для каждого типа данных использовать отдельную таблицу

Зачем?

Цитата(Litkevich Yuriy @ 20.11.2009, 15:51) *
Если кол-во типов ограничить:
...
то три таблицы надо, вполне нормально

Это не универсальное решение. Зачем себя ограничивать?)

Сообщение отредактировал Elfinit - 1.12.2009, 9:56
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 1.12.2009, 11:51
Сообщение #7


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9656
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Цитата(Elfinit @ 1.12.2009, 12:54) *
Зачем?
например, перечисленные выше типы данных, как хранить в одной таблице?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Elfinit
  опции профиля:
сообщение 1.12.2009, 21:40
Сообщение #8


Участник
**

Группа: Участник
Сообщений: 127
Регистрация: 17.3.2009
Из: Казань
Пользователь №: 619

Спасибо сказали: 7 раз(а)




Репутация:   1  


Есть таблички:
db_tables(id, name, description),
db_tables_fields(id, id_db_table, name, id_type, default_value, description)
types(id, name, description).

При вставке в db_tables должна создаваться таблица с именем name (триггер на insert)
Таблица types должна быть заполнена интересующими типами.
При вставке в db_tables_fields в таблицу по ссылке id_db_table должно вставляться поле, тип которого определяется по ссылке id_type.
Как-то так.

А если создавать для каждого типа свою таблицу, то как будет выглядеть логика? Например, в таблице int_values будут хранится ВСЕ целочисленные значения в БД? А как определить, к какой сущности они относятся? К какой конкретно записи? Как будут выглядеть запросы?

Раз уж проектируется универсальная структура ДБ, то ограничений должно быть как можно меньше. Нужно, чтобы было некое "ядро", через которое уже "раскручивается" нужная предметная область. Хотим, чтобы в ДБ были разные типы - значит их может быть сколько угодно. А ещё они могут быть ссылками. Применительно к конкретной предметной области "клиент" не должен видеть никакой кухни. Он говорит, допустим "хочу, чтобы в базе была такая-то сущность с такими-то сущностями" - "ядро" должно подготовить таблицу с нужными полями.
Думаю, полезно будет почитать, например, о том, как функционируют базы данных CMS.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 1.12.2009, 21:52
Сообщение #9


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9656
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Цитата(Elfinit @ 2.12.2009, 0:40) *
При вставке в db_tables должна создаваться таблица с именем name (триггер на insert)
в FireBird нельзя создавать объекты БД внутри тригеров и хранимых процедур.

Цитата(Elfinit @ 2.12.2009, 0:40) *
Например, в таблице int_values будут хранится ВСЕ целочисленные значения в БД?
ну я пока на этом остановился

Цитата(Elfinit @ 2.12.2009, 0:40) *
А как определить, к какой сущности они относятся? К какой конкретно записи?
иметь доп поле с идентификатором записи

для меня большей проблемой является не ограничение числа типов, трёх за глаза и зауши.
Для меня является проблемой "Сущность и её свойства" где-то сзади чешется, что свойства тоже являются сущностью, тогда где их держать?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
trdm
  опции профиля:
сообщение 2.12.2009, 1:43
Сообщение #10


Дмитрий Трошин
****

Группа: Участник
Сообщений: 575
Регистрация: 12.1.2008
Пользователь №: 68

Спасибо сказали: 21 раз(а)




Репутация:   6  


может хватит велик изобретать, а стоит посмотреть системные таблицы MS SQL....
:)
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

3 страниц V   1 2 3 >
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 9.8.2020, 20:57