К вопросу о культурном проектировании реляционных БД

← →
Kostafey © (2007-12-22 14:57) [0]

Работать-то оно может по-всякому, но абы-как почему-то больше не хочется.
Если это имеет в данном случае значение, использую MS SQL Server 2005.
Возникают у меня такие вопросы:

1)Каков должен быть регистр символов в названии таблиц, полей ?

2)Является ли нежелательным использование занака _ в названии таблиц, полей ?

3)Как лучше всего называть поля-иденитификаторы и внешние ключи

4)Критично ли использование излишних связей, например
есть таблицы Страна, Субъект(связанный со Страной), Город(связвнный с Субъектом),
так мы Город еще и к Стране привязываем

5)Допускается ли использовать 1 поле для хранения данных разных с точки
зрения модели БД.
Например есть следующая структура:
таблица Материалы_на_складе, поля:
Id_склада
Алюминий
Чугуний
Бетоний
Деревяний

заменяем на:

Таблица Материалы_на_складе, поля:
Id_склада
Вид_вещетсва
Количество

Таблица Вид_вещетсва, поля:
id_вида
Вид
Сответственно, 1 склад уже будут характеризовать несколько записей

6)Допускается ли исползовать одно и тоже поле в качестве внешнего
ключа к нескольким таблицам (информация к какой именно таблице является
внешним ключ в данной записи находиться в другом поле)

Буду очень признателен за любые советы.

← →
Petr V. Abramov © (2007-12-22 15:44) [1]

1. согласно внутреннему стандарту
2. см. 1.
3. осмысленно
4. некритично, но нежелательно без веских оснований, как и любая денормализация
5.

> заменяем на:

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

6. Допускается, но лучше не допускать.

← →
Kostafey © (2007-12-22 15:52) [2]

> [1] Petr V. Abramov © (22.12.07 15:44)
> 1. согласно внутреннему стандарту
> 2. см. 1.

Я и есть этот стандарт :)

> 3. осмысленно

Ну вот например, для приведенной в п.5 структуры:
Sklad
Id
Id_VidVeshestva
Kol

VidVeshestva
Id
Vid
Нормально?

> 5.
>
> > заменяем на:
>
> именно так и делаем.
> потму что как только появятся стекляний и оловяний, структура
> базы и куча кода полетит к чертям. Если кто-то от заказчика
> утверждает, что стекляний и оловяний не появятся никогда,
> покивай, но не верь.
>
> 6. Допускается, но лучше не допускать.

Понял, спасибо.

← →
Petr V. Abramov © (2007-12-22 15:57) [3]

> Kostafey © (22.12.07 15:52) [2]
я по-английски называю, кому-то больше транслитерацией нравится.
тут холивар большой был на эту тему.

← →
Petr V. Abramov © (2007-12-22 15:58) [4]

если называть по английски, ни у кого не возникнет подозрения, что проектировал первокурсник :)

← →
kaif © (2007-12-22 16:04) [5]

4. Либо устраняем поле Город в Субъекте, либо делаем внешний ключ сразу на два поля (Субъект.Город, Страна -> Город, Страна). Для этого Таблица Город должна иметь альтернативный уникальный ключ Город, Страна. Не знаю, позволяет ли MS SQL задавать внешние ключи на группу полей - IB позволяет. Я бы все же устранил поле Страна в Субъекте.
5. Однозначно требует нормализации.
6. Неужели MS SQL такое позволяет декларативно объявлять? Я бы так не стал делать, если честно. Уж лучше создать некий "журнал", в котором дублировать элементы из разных таблиц и на него ссылаться.

В общем, все что касается стандарта (регистр букв, названия полей) - дело вкуса и здесь важнее единообразие. А что касатся нормализации - лучше все изначально нормализовать по максимуму, а потом что-то с умом денормализовать.

← →
Kostafey © (2007-12-22 16:05) [6]

> [3] Petr V. Abramov © (22.12.07 15:57)
> > Kostafey © (22.12.07 15:52) [2]
> я по-английски называю, кому-то больше транслитерацией нравится.
> тут холивар большой был на эту тему.

Как же я пропустил его :)
Ссылочки не сохранилось?

> [4] Petr V. Abramov © (22.12.07 15:58)
> если называть по английски, ни у кого не возникнет подозрения,
> что проектировал первокурсник :)

Это почему?
Я вообще видел вперемешку написано.

← →
Petr V. Abramov © (2007-12-22 16:07) [7]

> Kostafey © (22.12.07 16:05) [6]
> Я вообще видел вперемешку написано
говорит об отсутствии стандартов

← →
kaif © (2007-12-22 16:15) [8]

Правильно писать Id_VidVeschestva
:))

← →
Kostafey © (2007-12-22 16:16) [9]

> [7] Petr V. Abramov © (22.12.07 16:07)
> > Kostafey © (22.12.07 16:05) [6]
> > Я вообще видел вперемешку написано
> говорит об отсутствии стандартов

Вот и хочу я его ввести.
Но из пальца высасывать - одно, сходить за советом - другое.

> [5] kaif © (22.12.07 16:04)
> 4. Либо устраняем поле Город в Субъекте,

Так и нет его.
Структура такова:
Страна:
ИД
Название
Субъект:
ИД
ИД_Страны
Название
Город:
ИД
ИД_Субъекта
ИД_Страны
Название

> 5. Однозначно требует нормализации.

Угу, понял.

> 6. Неужели MS SQL такое позволяет декларативно объявлять?

Ну вот товарищ умудрился.

> Уж лучше создать некий "журнал", в котором дублировать элементы
> из разных таблиц и на него ссылаться.

Это как?

> В общем, все что касается стандарта (регистр букв, названия
> полей) - дело вкуса и здесь важнее единообразие. А что касатся
> нормализации - лучше все изначально нормализовать по максимуму,
> а потом что-то с умом денормализовать.

Согласен. Спасибо.

← →
Kostafey © (2007-12-22 16:18) [10]

> [8] kaif © (22.12.07 16:15)
> Правильно писать Id_VidVeschestva
> :))

Да, у меня где-то валялась таблица транслита :)

← →
Petr V. Abramov © (2007-12-22 16:30) [11]

я так думаю 6. напрямую растет из 5.

← →
Kostafey © (2007-12-22 16:33) [12]

> [11] Petr V. Abramov © (22.12.07 16:30)
> я так думаю 6. напрямую растет из 5.

Не совсем понял. Это как?

← →
kaif © (2007-12-22 16:34) [13]

> Уж лучше создать некий "журнал", в котором дублировать элементы
> из разных таблиц и на него ссылаться.

Это как?

Допустим у Вас имеется 4 таблицы: счета выставленые, счета полученные, накладные исходящие, накладные входящие. И еще могу появиться новые таблицы со своеобразными полями.
А Вы хотите иметь общую подчиненную таблицу позиций с одинаковой структурой для всех подобных документов. Содержащую поля: товар, кол-во, цена без НДС, НДС.
Тогда можно сделать общий "журнал", в который переписывать строки из тех 4 таблиц в каком-то сокращенном виде, например в виде ID, тип документа, дата, сумма, а на него ссылаться из талицы позиций.

← →
Kostafey © (2007-12-22 16:41) [14]

> [13] kaif © (22.12.07 16:34)
> > Уж лучше создать некий "журнал", в котором дублировать
> элементы
> > из разных таблиц и на него ссылаться.
>
> Это как?

Понял, но требуется не сокращенная, а полная информация.

Как вариант решения:
Сделать в общей подчиненной таблице поля-внешние ключи ко
всем таблицам Счетов, и отдельно поле для того, чтобы
характеризовать к какой именно таблице счетов
следует обращаться в текущей записи.

← →
kaif © (2007-12-22 16:42) [15]

Это позволит сделать более изящную навигацию и фильтрацию документов, не прибегая к конструкциям типа UNION.
В принципе подобные "журналы" и есть некоторый безопасный способ денормализации.
Сначала мы все строго разбиваем на отдельные сущности, а потом строим журналы, в которых эти сущности объединяем по наиболее общим полям.
Злоупотреблять этим не стоит, но иногда выигрыш может быть невероятным.
Представьте себе 50 таблиц типизированных товаров с их особенными полями и общий журнал - таблицу, в которую сведены просто их ID и наименование. В таких случаях удобно иметь сквозной уникальный ID на все товары. В IB для этого удобно использовать генераторы. В MS SQL не знаю. ГУИДы какие-нибудь страшные, возможно, сойдут :)

← →
kaif © (2007-12-22 16:43) [16]

Kostafey © (22.12.07 16:41) [14]
Сделать в общей подчиненной таблице поля-внешние ключи ко
всем таблицам Счетов, и отдельно поле для того, чтобы
характеризовать к какой именно таблице счетов
следует обращаться в текущей записи.

Я не представляю, как такое можно объявитьв MS SQL.
И еще меньше я себе представляю, как потом делать SQL-запросы, например, как запросить все "позиции", объединенные с их "шапками".

← →
Sergey Masloff (2007-12-22 16:52) [17]

1-4 к проектированию отношения не имеют.
5 Так и нужно в большинстве случаев
6 Если нельзя но очень хочется (и можешь обосновать почему хочется) то можно

← →
Kostafey © (2007-12-22 16:56) [18]

> [16] kaif © (22.12.07 16:43)
Я не представляю, как такое можно объявитьв MS SQL.

Склад
Ид_бетония
Ид_чугуния
Нужный_Ид //1-бетоний, 2-чугуний

Бетоний
ИД
прочие_поля

Чугуний
ИД
прочие_поля

пример содержимое таблицы Склад:
ИД | Ид_бетония | Ид_чугуния | Нужный_Ид
0 | 34 | null | 1
1 | 45 | null | 1
2 | null | 13 | 2
3 | null | 89 | 2

> И еще меньше я себе представляю, как потом делать SQL-запросы,
> например, как запросить все "позиции", объединенные с их
> "шапками".

SELECT * FROM Склад JOIN Бетоний on (Бетоний.ИД = Склад.Ид_бетония) WHERE Склад.Нужный_Ид = 1 UNION SELECT * FROM Склад JOIN Чугуний on (Чугуний.ИД = Склад.Ид_чугуния) WHERE Склад.Нужный_Ид = 2

← →
Kostafey © (2007-12-22 17:01) [19]

> [17] Sergey Masloff (22.12.07 16:52)
> 1-4 к проектированию отношения не имеют.

Согласен, я просто думал есть какой-то аналог
Code Conventions :)

> 5 Так и нужно в большинстве случаев

Уяснил.

> 6 Если нельзя но очень хочется (и можешь обосновать почему
> хочется) то можно

Хорошо, ну а как вообще тогда реализовывать обсуждаемое в

> [14] Kostafey © (22.12.07 16:41)

← →
Sergey Masloff (2007-12-22 17:17) [20]

Kostafey © (22.12.07 17:01) [19]
А я не понял что обсуждается. Типа "наследования"? Когда в двух таблицах с разными сущностями много похожих полей? Типа "юр.лица" и "физ. лица" но все они "клиенты"? Можно в одну таблицу вынести все общее. Тебя беспокоит что поле ID в этой таблице в зависимости от типа клиента будет ключем на таблицу - "расширение"?
Я бы сделал главной таблицей "клиенты" под ней 1:1 "таблицы расширений"
Поставил бы защиту от редактирования на "главную" а при записи в "детальные" заполнял бы и "главную". Как один из вариантов, на самом деле имеющих право на жизнь вариантов много

← →
Johnmen © (2007-12-22 17:19) [21]

Допустимо всё, что напрямую не запрещено теорией.
Применяем правила нормализации, но имеем право от них отступать, если это даст эффект в скорости, объеме и т.п.
Всё остальное неспешный трёп :)
Если есть конкретный вопрос, то именно его и следует обсасывать...

← →
Sergey Masloff (2007-12-22 17:20) [22]

Johnmen © (22.12.07 17:19) [21]
>Допустимо всё, что напрямую не запрещено теорией.
Я бы расширил: даже то что запрещено теорией можно иногда нарушать (если есть уверенность в своей правоте и возможность проверить)

← →
Johnmen © (2007-12-22 17:23) [23]

> Sergey Masloff (22.12.07 17:20) [22]

Да, пожалуй.

← →
kaif © (2007-12-22 17:26) [24]

В общем, нарушение правил нормализации, как и правил дорожного движения, должно быть осознанным и точно рассчитанным. Иначе неминуемы ДТП.

← →
Kostafey © (2007-12-22 17:48) [25]

> [20] Sergey Masloff (22.12.07 17:17)
> Kostafey © (22.12.07 17:01) [19]
> А я не понял что обсуждается. Типа "наследования"? Когда
> в двух таблицах с разными сущностями много похожих полей?
> Типа "юр.лица" и "физ. лица" но все они "клиенты"? Можно
> в одну таблицу вынести все общее. Тебя беспокоит что поле
> ID в этой таблице в зависимости от типа клиента будет ключем
> на таблицу - "расширение"?

Отличный пример. В [18] Kostafey © (22.12.07 16:56)
я хотел лишь продемонстрировать механизм, но никак не
сущность.

> Я бы сделал главной таблицей "клиенты" под ней 1:1 "таблицы
> расширений"

Т.е. все-таки "1 поле связи на все детальные", вместо
"на каждую детальную - свое поле как в [18]"

> Поставил бы защиту от редактирования на "главную" а при
> записи в "детальные" заполнял бы и "главную". Как один из
> вариантов, на самом деле имеющих право на жизнь вариантов
> много

Не совсем понял. Т.е. редактирование таблиц
осущствляем только вместе: голавная + детальная?
Ну так программно оно так и реализуется.
Или имеется в виду реализовать в самой БД?

← →
MsGuns © (2007-12-22 19:51) [26]

Советую прежде чем приступать к проектированию таблиц (полей таблиц, межтабличных связей и т.д.) "нарисовать" объектную модель предмета автоматизации, в которой каждую конечную сущность ("Страна", "Склад", "Материал", "Документ" и т.д.) представить объектом с характеристиками (свойствами), адекватно описывающими этот объект.
Затем свойства всех объектов поместить в сводную таблицу характеристик, по которой уже можно приступать к номрмализации.
Создание таблиц вместе с полями выполнять только после того, как "прояснится на доске", то бишь на сводной таблице

← →
tesseract © (2007-12-22 21:43) [27]

> Советую прежде чем приступать к проектированию таблиц (полей
> таблиц, межтабличных связей и т.д.) "нарисовать" объектную
> модель предмета автоматизации, в которой каждую конечную
> сущность ("Страна", "Склад", "Материал", "Документ" и т.
> д.)

UML-ом попахивает. На самом деле после 2-3 лет работы автоматически проектируешь. Как привык на данной платформе. Но сущности это все фигня, вот когда сводные таблицы движений/остатков начинаешь делать, вот тут трижды подумаешь какую избыточность вносить.

> А я не понял что обсуждается. Типа "наследования"? Когда
> в двух таблицах с разными сущностями много похожих полей?
> Типа "юр.лица" и "физ. лица" но все они "клиенты"? Можно
> в одну таблицу вынести все общее.

Это уже объектно-реляцоныые базы называеться. Постгресс, cache, Oracle умеют с такими данными работать. Очень кстати удобно при рефакторинге базы - код можно не трогать.

← →
MsGuns © (2007-12-22 21:50) [28]

>tesseract © (22.12.07 21:43) [27]

>UML-ом попахивает. На самом деле после 2-3 лет работы автоматически проектируешь.

Есть такие предметные области, что и 20 лет опыта не хватает, чтобы "автоматически проектировать"

> Kostafey © (22.12.07 15:52) [2]
> > [1] Petr V. Abramov © (22.12.07 15:44)
> > 1. согласно внутреннему стандарту
> > 2. см. 1.
>
> Я и есть этот стандарт :)

Много на себя ведешь, СУБД имеет возможность дать тебе по ушам

> 1)Каков должен быть регистр символов в названии таблиц,
> полей ?

От самой базы зависит. В InterBase принято все поля вводить заглавными буквами. В табличках DBF - также. В Paradox - прописные и строчные буквы чередуются. Лучше просто смотреть поставляемые с СУБД примеры и придерживаться того же стиля.

> 2)Является ли нежелательным использование занака _ в названии
> таблиц, полей ?

В InterBase данный символ - стандарт. В Paradox - практически не применяется. Насчет MS SQL Server - не знаю. Рекомендация та же, что и в предыдущем пункте.

> 3)Как лучше всего называть поля-иденитификаторы и внешние
> ключи

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

> 4)Критично ли использование излишних связей, например
> есть таблицы Страна, Субъект(связанный со Страной), Город(связвнный
> с Субъектом),
> так мы Город еще и к Стране привязываем

Все правильно! Их следует связывать, причем именно в таком порядке!

> 5)Допускается ли использовать 1 поле для хранения данных
> разных с точки
> зрения модели БД.
> Например есть следующая структура:
> таблица Материалы_на_складе, поля:
> Id_склада
> Алюминий
> Чугуний
> Бетоний
> Деревяний

Если набор материалов фиксированный, то ради бога! Можно и так! Но чаще всего каждый материал обладает каким-то набором дополнительных свойств. К тому же номенклатура материалов может расширяться! Тогда данная схема становится неудобной.

> заменяем на:
>
> Таблица Материалы_на_складе, поля:
> Id_склада
> Вид_вещетсва
> Количество
>
> Таблица Вид_вещетсва, поля:
> id_вида
> Вид

> Сответственно, 1 склад уже будут характеризовать несколько
> записей

Это более гибкий подход!

> 6)Допускается ли исползовать одно и тоже поле в качестве
> внешнего
> ключа к нескольким таблицам (информация к какой именно таблице
> является
> внешним ключ в данной записи находиться в другом поле)

Ну это уже какое-то извращение!

> Так и нет его.
> Структура такова:
> Страна:
> ИД
> Название
> Субъект:
> ИД
> ИД_Страны
> Название
> Город:
> ИД
> ИД_Субъекта
> ИД_Страны - это здесь совершенно ненужно, т.к. субъект однозначно определяет страну!
> Название

> tesseract © (22.12.07 21:43) [27]
Oracle умеют с такими данными работать. Очень кстати удобно при рефакторинге базы - код можно не трогать.
и Oracle это не умеет, и код надо трогать :)
11-й Oracle пока не трогал :)

> [26] MsGuns © (22.12.07 19:51)

Вот все это, конечно хорошо, минус в том, что есть некая
преемственность от старых решений.
БД уже была реализована в Access и эксплуатировалась,
проектировалоса она - абы работало.
Я за то чтоыб проектировать с 0, но заказчик ничего
другого как модифицировать уже сделанную в Access БД
и знать не хочет.

> [29] Anatoly Podgoretsky © (22.12.07 21:53)
> > Я и есть этот стандарт :)
>
> Много на себя ведешь, СУБД имеет возможность дать тебе по
> ушам

MS SQL Server точно не даст: хоть по-русски поля называй, не даст.

> [30] Loginov Dmitry © (22.12.07 23:54)
> Прежде всего имя любого поля лучше всего начинать с префикса
> - 2-3 символа, являющиеся сокращением имени таблицы. Этому
> правилу поддаются и поля-идентификаторы. При этом придумывать
> имена внешних ключей нет необходимости - они уже известны,
> т.к. являются первичными ключами связанных таблиц.

Раньше я так и делал. При небольшом количестве таблиц - очень удобно:
Gruppa:
G_id
G_name
Student:
S_id
S_FIO
S_G_id //В какой группе студент

Select *
Form Student, Gruppa
Where S_G_id=G_id

Но когда таблиц много, я думаю лучше пользоваться
полным именем поля, т.е.:

Gruppa:
id
name
Student:
id
FIO
Gruppa_id //В какой группе студент

Select *
Form Student, Gruppa
Where Student.Gruppa_id=Gruppa.id

> MS SQL Server точно не даст: хоть по-русски поля называй,
> не даст.

Даст, поскольку и там можно сделать чувствительность к регистру.

> 1)Каков должен быть регистр символов в названии таблиц,
> полей ?

> Раньше я так и делал. При небольшом количестве таблиц 
> очень удобно:
> Gruppa:
> G_id
> G_name
> Student:
> S_id
> S_FIO
> S_G_id //В какой группе студент
>
> Select *
> Form Student, Gruppa
> Where S_G_id=G_id

Появляется еще одна таблица, название которой начинается на G и через некоторое время возникнет небольшая путаница, что же такое G_id (к какой именно таблице оно относится).

Я обычно делаю так. Поле «Код» в любой таблице всегда называется ID, а ссылки на другие таблицы маркируются как ID_ИмяТаблицы: ID_GROUP, ID_STUDENT etc.

> > 6)Допускается ли исползовать одно и тоже поле в качестве
>
> > внешнего
> > ключа к нескольким таблицам (информация к какой именно
> таблице
> > является
> > внешним ключ в данной записи находиться в другом поле)

А приведите пример, чтобы необходимо было использовать такой подход?

> 2)Является ли нежелательным использование занака _ в названии таблиц, полей ?

Я часто использую нижнее подчеркивание. Как здесь говорили, очень удобно таблицы группировать с помощью префикса. Например, AGR_, STR_, FIN_, CMT_
Да и если таблица называется замудренно, легче читать с подчеркиванием (из увиденного недавно: CLIENTSGROUPSRELATIONS, мне удобнее прочесть CLIENTS_GROUPS_RELATIONS, хотя конечно название изначально неудачное, уж слишком много букв :)

> 1)Каков должен быть регистр символов в названии таблиц,
> полей ?
>
> 2)Является ли нежелательным использование занака _ в названии
> таблиц, полей ?
>
> 3)Как лучше всего называть поля-иденитификаторы и внешние
> ключи

Главное все это называть однообразно. Т.е. в соответствии с каким-нибудь стандартом, пусть даже собственным, внутренним.

> Раньше я так и делал.

Еще одна жертва венгерской нотации и работа с Паскалем не помогла.

> и Oracle это не умеет, и код надо трогать :)11-й Oracle
> пока не трогал :)

Вроде заявляли, что наследование поддерживаеться. Слоник умеет. Имееться в виду заводишь например документ отнаследованный от другого, добавляешь ему поле и переписываешь только код для этого документа.

> tesseract © (24.12.07 11:56) [38]
поддерживается, даже работает без особых глюков.
только на "добавленное поле" foreign key нельзя поставить, по крайней мере, у меня не получилось.
Синтаксические возможности есть, но не создается, выдает идиотские ошибки.
Поэтому ценность приближается к нулю

> [35] Бакук © (24.12.07 05:11)

> А приведите пример, чтобы необходимо было использовать такой
> подход?

[20] Sergey Masloff (22.12.07 17:17)
очень хороший пример привел.

Со всем остальным согласен на 100%

> [37] Anatoly Podgoretsky © (24.12.07 11:14)
> > Раньше я так и делал.
> Еще одна жертва венгерской нотации и работа с Паскалем не
> помогла.

Каюсь, ибо я грешен, :)
теперь делаю по-другому
см. [33] Kostafey © :
> Но когда таблиц много, я думаю лучше пользоваться
> полным именем поля, т.е.:
>
> Gruppa:
> id
> name
> Student:
> id
> FIO
> Gruppa_id //В какой группе студент
>
> Select *
> Form Student, Gruppa
> Where Student.Gruppa_id=Gruppa.id

К вопросу о культурном проектировании реляционных БД Найти похожие ветки