Подскажите по проектировке таблиц БД.

← →
MonoLife © (2012-09-28 13:40) [40]

> Inovet © (28.09.12 13:32) [38]
>
> По сабжу присоединяюсь к положительным отзывам.

спасибо, значит я на правильном пути

← →
Inovet © (2012-09-28 13:40) [41]

> [39] AV © (28.09.12 13:34)

Вместо только и остаётся.

← →
AV © (2012-09-28 13:58) [42]

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

Автор, это вообще, что такое? попросили лаб.раб сделать или что?

← →
Jeer © (2012-09-28 14:02) [43]

Часть проэкта по созданию новых сущностей на Земле :)
Люди с крыльями, собаки с плавниками, дельфины-экранопланы и т.д....

← →
AV © (2012-09-28 14:13) [44]

> Люди с крыльями, собаки с плавниками, дельфины-экранопланы
> и т.д....

Ну.. тут два варианта, либо запрос кривой, либо в кофе много градусов было :)

← →
MonoLife © (2012-09-28 14:22) [45]

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

по подробнее, плз!

> Автор, это вообще, что такое? попросили лаб.раб сделать
> или что?

или что.. ) Давно ничего не делал с БД, тут думаю, дай-ка спроектирую что-нить... На ферме пригодится..

← →
AV © (2012-09-28 14:38) [46]

Таблица для связи
id, id_atri, id_pets, id_color

1 - лапы - кошка - зеленый
2 - лапы - собака - null (т.е .брать цвет, как сама собака)
3 - хвот - кошка - облезлый :)

← →
MonoLife © (2012-09-28 14:43) [47]

> AV © (28.09.12 14:38) [46]

Благодарю. В твоем примере атрибуты (конечности) выступают первыми.. В первом посте я не стал спрашивать, но может надо было.. К атрибутам прикреплять животных? Или это не правильно?

← →
Игорь Шевченко © (2012-09-28 14:52) [48]

Автор, ты чего делаешь-то ?

А то еще одну цитату почитай:

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

create table objects (oid int pimary key, name varchar2(255));
create table attributes (attrid int primary key, attrname varchar2(255),
datatype varchar2(25));
create table object_attributes (oid int, attrid int, value varchar2(4000),
primary key (oid,attrid));
create table links (oid1 int, oid2 int, primary key (oid1, oid2));

Но как такая модель работает ? Простой запрос select first_name, last_name from person трансформируется в соединение трех таблиц с аггрегированием, более того, если имеются атрибуты NULLABLE - в таком случае может не быть строки в таблице object_attributes для некоторых атрибутов, - возможно, возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

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

(с) Том Кайт "Эффективное проектирование приложений Oracle"

← →
Jeer © (2012-09-28 14:53) [49]

Для того и существуют справочники, чтобы локализовать ( обосабливать ) классифицирующие сущности.

← →
MonoLife © (2012-09-28 15:06) [50]

Хорошо. На данном этапе, я хочу уяснить наличие каких полей мне нужно в таблицах "животные", "масть", "атрибуты(конечности)" и т.п.
Что получается, соответственно:
id_pets,name_pets
id_atri, name_atri
id_color, name_color
таблица связи:
id, id_pets, id_atri, id_color
Этого достаточно?
В дальнейшем, я смогу обращаться к таблице связи с любым запросом по этим параметрам..

← →
MonoLife © (2012-09-28 15:17) [51]

что-то просто как-то..

← →
Игорь Шевченко © (2012-09-28 15:21) [52]

а чем Color отличается от Attribute ?

← →
Jeer © (2012-09-28 15:26) [53]

> Игорь Шевченко © (28.09.12 15:21) [52]
>
> а чем Color отличается от Attribute ?

Полагаю, что цвет аттрибутов может быть разным :)

← →
MonoLife © (2012-09-28 15:31) [54]

> Полагаю, что цвет аттрибутов может быть разным :)

О, точно!
Как в таком случае? То есть, цвет есть и у животных, и у их частей тела..
Как будут выглядеть таблицы в этом случае?

← →
Jeer © (2012-09-28 15:35) [55]

Для модели животного - некий общий цвет.
Для каждого аттрибута тоже цвет, а может еще какие признаки.

А по делу - начать с биологической систематики :)
http://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0

← →
Игорь Шевченко © (2012-09-28 15:36) [56]

> Полагаю, что цвет аттрибутов может быть разным :)

Тогда нужно вводить атрибуты атрибутов

← →
Труп Васи Доброго © (2012-09-28 15:36) [57]

> id, id_pets, id_atri, id_color

Вот хоть что говорите, а эта таблица не нормализована, лишний ID и всё тут.
Если уж доходить до универсальности, то чтобы собрать любую животину с любым набором любых характеристик то тогда таблица связи должна быть такой.
ID, Svaz_str
где Svaz_str строка связи вида "Tab1_name, Tab1_id, Tab2_name, Tab2_id, ..., TabN_name, TabN_id".
Тогда можешь под каждое свойство создавать таблицу, а в эту строку записывай произвольный набор характеристик.

← →
vuk © (2012-09-28 15:37) [58]

to Игорь Шевченко © (28.09.12 14:52) [48]:

> Простой запрос select first_name, last_name from person
> трансформируется в соединение трех таблиц с аггрегированием

Если до маразма доводить, то конечно трансформируется, не вопрос. Просто во всём надо меру знать. Универсальные схемы с атрибутами нужны, когда требуется учет разнородных сущностей. Если же сущности однородны (ну, вот есть у person first_name и last_name), то схема должна быть специализированной.

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

В угол себя загоняют те, кто пользуется догмами.

← →
Jeer © (2012-09-28 15:39) [59]

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

Сломал голову, глаза, компьютер.. плюнул и сейчас отдаю фотки на растерзание профессионалам.

http://www.plantarium.ru/

← →
MonoLife © (2012-09-28 15:39) [60]

> Для модели животного - некий общий цвет.

:)

> А по делу - начать с биологической систематики :)

это не важно.. По большому счету, взять за пример можно любую сложную классификацию, а не такую упрощенную, что в моем примере.

В общем, спасибо всем.. если всё так просто, значит я не те вопросы задаю..

← →
Jeer © (2012-09-28 15:43) [61]

Таксоны:

Жизненная форма
Дерево
Вечнозелёное
Внешний вид
Побеги
Тип
Прямостоячие
Листорасположение
Очерёдное
Размещение листьев
Ближе к верхушке
Листья
Тип
Сложные
Пластинка
Форма
Ланцетная
Членение
Перистое
Порядки сложности
1
Прикрепление
Черешковое
Доли
Форма
Ланцетная
Линейная
Верхушка
Острая
Край
Гладкий
Подогнутый
Основание
Клиновидное
Поверхность
Кожистая
Опушение
Густое
Рассеяное
Мягкое или шелковистое
Оттопыренное
Прижатое
Курчавое
на молодых листьях
Плоды
Тип
Сочный
Костянка
на самом деле - семя, покрытое кожистой оболочкой
Шишки
Консистенция
Сухие
Форма
Вытянутые
Местообитание
Антропогенное
Обочина дороги
Парк или сад
Экология
Отношение к влаге
Ксерофит
Мезофит
Отношение к питанию
Мезотроф
Эвтроф
Отношение к свету
Светолюбивое
Особенности
Декоративное
Культивируемое
Русскоязычные названия
Комментарии и обсуждения
Научные:
Саговник отвёрнутый
Саговник отогнутый
Саговник поникающий
Систематика
отдел Pinophyta
класс Cycadopsida
порядок Cycadales
семейство Cycadaceae
род Cycas
вид revoluta Thunb

← →
MonoLife © (2012-09-28 15:44) [62]

> Jeer © (28.09.12 15:43) [61]

я почему-то тоже в таксоны сразу уперся)

← →
Jeer © (2012-09-28 15:45) [63]

Т.е. для тебя надо эмулировать в реляционной базе иерархически связанные сущности.

← →
Anatoly Podgoretsky © (2012-09-28 15:47) [64]

> Jeer (28.09.2012 15:35:55) [55]

Красный хвост

← →
Anatoly Podgoretsky © (2012-09-28 15:49) [65]

> Jeer (28.09.2012 15:45:03) [63]

Или использовать иерархическую БД

← →
Jeer © (2012-09-28 15:50) [66]

Ну да:
красный хвост, синие глаза, ласковые руки, блондинка.. :)

← →
Jeer © (2012-09-28 15:51) [67]

> Anatoly Podgoretsky © (28.09.12 15:49) [65]
>
> > Jeer (28.09.2012 15:45:03) [63]
>
> Или использовать иерархическую БД

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

← →
Anatoly Podgoretsky © (2012-09-28 15:51) [68]

Это что бы не вводить новые сущности - хвосты.цвет, глаза.цвет, пол

> Т.е. для тебя надо эмулировать в реляционной базе иерархически
> связанные сущности.

пожалуй, да

> В угол себя загоняют те, кто пользуется догмами.

Да-да, в том числе и догмой об универсальных схемах :)

to Игорь Шевченко © (28.09.12 16:13) [70]:

> Да-да, в том числе и догмой об универсальных схемах :)

Совершенно верно. Любая догма - кривая штука, в том числе и об универсальных схемах. Равно как и специализированных. Поэтому, если на практике нужна универсальная, упираться в специализированные - глупость. Равно как и обратное упиралово. :)

Смотря что понимать под "догмой". Если это просто некий набор принципов или правил, "возникших" в результате опыта, то что в этом плохого ?
Другое дело, эти правила могут устаревать и терять эффективность.

Например догма "не пользоваться суррогатами"

Многие товарисчи, в т.ч. и достаточно известные и заслуженные, руководствуются именно этой догмой до сих пор. И ладно если б мовчки.
Так нет ! Надо при каждом случае выливать тазы помоев на "суррогатчиков", приводя в качестве аргументов смешные вещи типа "избыточности"

А ведь есть ситуации (вполне жизненные) когда нативного объяснения просто необходимой "базовой" сущности просто не существует (например при конвертации или объединении баз) .

vuk © (28.09.12 16:22) [71]

Поэтому, не узнав задачи, трудно давать квалифицированный ответ - я имею в виду вопрос автора ветки :)

> Игорь Шевченко © (28.09.12 16:46) [73]

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

> хм.. задача спроектировать таблицы связанных сущностей?

Это не задача, это один из методов реализации

to MsGuns © (28.09.12 16:41) [72]:
> Смотря что понимать под "догмой".

Что-то типа "мы вот тут в книжке прочитали и теперь всегда будем делать так и не иначе".

to Игорь Шевченко © (28.09.12 16:46) [73]:
> Поэтому, не узнав задачи, трудно давать квалифицированный
> ответ - я имею в виду вопрос автора ветки :)

Согласен абсолютно.

to Anatoly Podgoretsky © (28.09.12 19:48) [77]:

> Это значит, что реляционная сущность не совсем подходяще
> для задачи.

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

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

Удалено модератором

Подскажите по проектировке таблиц БД. Найти похожие ветки