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

← →
MonoLife © (2012-09-28 09:57) [0]

Есть таблица "животные", есть - "атрибуты".
Как правильно связать? К примеру:
кошка => + лапы + хвост + усы крылья клюв курица => + лапы + хвост усы + крылья + клюв и т.п...
Причем, "атрибутов", скорее меньше, чем "животных"..
Как мне кажется, структура полей таблиц должна быть такова:
Животные
id_pets,Name_pets
Атрибуты (как бы справочник)
id_atri, name_atri
Таблица для связи
id, id_atri, id_pets

То есть, "Таблица для связи" будет набита повторяющимися значениями атрибутов для каждого id животного?

← →
Jeer © (2012-09-28 10:01) [1]

Нормально, сойдет.

← →
MonoLife © (2012-09-28 10:11) [2]

> Нормально, сойдет.

спасибо!)

← →
Ega23 © (2012-09-28 10:46) [3]

> То есть, "Таблица для связи" будет набита повторяющимися
> значениями атрибутов для каждого id животного?

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

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

> Нормально, сойдет.

Нет, это не НОРМАЛЬНО. Чтобы стало нормально в таблице связей надо выбросить ID, это избыточная информация.

← →
Ega23 © (2012-09-28 10:54) [5]

> Нет, это не НОРМАЛЬНО. Чтобы стало нормально в таблице связей
> надо выбросить ID, это избыточная информация.

Это суррогатный ключ. Бывает полезен, бывает вреден, бывает нейтральным.

← →
AV © (2012-09-28 10:59) [6]

> в таблице связей надо выбросить ID

не знаю..
Мне, видя таблицу без собственного id, хочется расстрелять owner"a :)

← →
MsGuns © (2012-09-28 10:59) [7]

>Чтобы стало нормально в таблице связей надо выбросить ID, это >избыточная информация.

Угу, и в качестве идентификации котов и кур использовать их фотографии.

← →
MonoLife © (2012-09-28 11:03) [8]

> Труп Васи Доброго © (28.09.12 10:47) [4]
> ...надо выбросить ID...

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

> Ega23 © (28.09.12 10:46) [3]

без дополнительной таблицы, было б так?
Атрибуты
id, name_atri, id_pets

← →
Anatoly Podgoretsky © (2012-09-28 11:06) [9]

Это отношение многие ко многим M-M

← →
MonoLife © (2012-09-28 11:08) [10]

> Это отношение многие ко многим M-M

это если
> без дополнительной таблицы
>
?

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

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

← →
Anatoly Podgoretsky © (2012-09-28 11:16) [12]

> MonoLife (28.09.2012 11:13:11) [11]

Надо что то выпить и почитать про M-M

← →
Ega23 © (2012-09-28 11:18) [13]

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

Вот сразу видно грамотного проектировщика баз, не то что некоторые.

← →
Ega23 © (2012-09-28 11:21) [14]

> без дополнительной таблицы, было б так?

Без дополнительной у таблицы животных было бы поле Attribs_IDs. Где в каком-нибудь виде хранились бы все ID атрибутов, присущих данному животному.
Иногда это выгоднее, например в угоду скорости.

← →
AV © (2012-09-28 11:21) [15]

> MonoLife © (

нормально все.

> типа, "хищники, травоядные",

значения типа да-нет, можно прямо в табле хранить. Или сделать отдельную таблу, а не в табле с общими аттрибутами. Как раз денормализация тут оправдана будет.

← →
Игорь Шевченко © (2012-09-28 11:22) [16]

> Мне, видя таблицу без собственного id, хочется расстрелять
> owner"a :)

Joe Celko называет таких разработчиков ID-иотами

"What is funny to me is the number of idiots who replace a natural
two- or three-integer compound key with a huge GUID, which no
human being or other system can possibly understand, because they
think it will be faster and easy to program"
(с) Joe Celko, SQL Programming Style

← →
Игорь Шевченко © (2012-09-28 11:23) [17]

Не удержусь процитировать:

"Real SQL programmers use real keys and do not try to imitate 1950"s
magnetic
tape or punch card systems in a relational model. In the early days of
programming languages, we exposed a lot of the physical and hardware
implementation to the programmer. For example, COBOL and FORTRAN depend
on
physically contiguous storage of data, which made a ROWID (i.e. physical
location reference) possible.

Later, we designed languages to independent of any physical and hardware
implementation. Thus, an INTEGER datatype did not have to be eight
binary
bits in a two complement format. It just had to behave like an integer
in
the program and the programmer did not have to worry about how the
hardware
did its work -- or even know what the hardware was.

SQL and other modern programming languages carry this idea further and
try
to completely separate logical and physical implementations. The idea
is
that SQL is based on sets (which have no ordering) and a standard that
defines its logical behavior. The behavior has nothing to do with
whether a
product uses B-Tree indexes, bit vectors or hashing; two complement or
base
ten arithmetic; whether the host program calling the SQL is C or Cobol;
etc.

The IDENTITY column in SQL Server is an attempt to return to those
thrilling
days of yesteryear, and the conceptual junk left over from the days when
people did not know much about relational databases. What we knew was
sequential file systems -- punch cards and magnetic tapes. Even the
disk
file systems mimicked these systems, adding only simple indexes.

Sequence was a basic way of looking at data. People thought in terms of
them at a primitive level. A sequence of bits make a byte, a sequence
of
bytes make a field, a sequence of fields make a record and sequence of
records make a file. Very low level, very close to the machinery.

Then along comes the relational model. It is based on sets; a set is a
completed whole, without any ordering to it. No sequences! Very
abstract!
"

Оттуда же

← →
AV © (2012-09-28 11:29) [18]

> Joe Celko называет таких разработчиков ID-иотами

да ну нафик,
id - number ( можно из сиквенса (можно на триггер на вставку поставить)).

where id = XYZ, всяко лучше писать, чем
where A = X and B = Y and C = Z

← →
Ega23 © (2012-09-28 11:30) [19]

> Не удержусь процитировать:

Категоричность - это плохо. Иногда - вредно. Иногда - полезно. Иногда - никому не нужно.
Я, например, с трудом представляю, как без GUID-а быть, когда репликацию надо делать.

← →
AV © (2012-09-28 11:34) [20]

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

← →
Anatoly Podgoretsky © (2012-09-28 11:39) [21]

> Ega23 (28.09.2012 11:30:19) [19]

Ты сменил контекст

← →
stone (2012-09-28 11:48) [22]

> Ega23 © (28.09.12 11:21) [14]
> Иногда это выгоднее, например в угоду скорости.

Зависит от СУБД. Так в MSSQL никто не мешает сделать индексированную вьюху. В результате и скорость и нормализация.

← →
Павел Калугин © (2012-09-28 11:59) [23]

> Категоричность - это плохо. Иногда - вредно. Иногда - полезно.
> Иногда - никому не нужно.
> Я, например, с трудом представляю, как без GUID-а быть,
> когда репликацию надо делать.

Есть еще хуже. Я вот совсем не представляю естественный ключ для данный физлица

← →
MonoLife © (2012-09-28 12:15) [24]

> Anatoly Podgoretsky © (28.09.12 11:16) [12]
>
>
> Надо что то выпить и почитать про M-M
>

пока, кроме коньяка на ум ничего не приходит, тяпница ведь..)

> Ega23 © (28.09.12 11:21) [14]

спасибо!

> AV © (28.09.12 11:21) [15]

Ну, для подобного - да, а для "кошек" видимо, опять заводить таблицу с их мастью..
> Игорь Шевченко © (28.09.12 11:22) [16]

Вот за что люблю ДМ, не только ответ на вопрос получишь, но еще кучу всякой дополнительной инфы:)

← →
Anatoly Podgoretsky © (2012-09-28 12:23) [25]

> MonoLife (28.09.2012 12:15:24) [24]

Я вообще то кофе имел ввиду :-)

← →
Anatoly Podgoretsky © (2012-09-28 12:23) [26]

> Anatoly Podgoretsky (28.09.2012 12:23:25) [25]

Кофе хороший депресант

← →
MonoLife © (2012-09-28 12:26) [27]

> Кофе хороший депресант

и "хорошее" мочегонное ср-во)

← →
Ega23 © (2012-09-28 12:27) [28]

> Зависит от СУБД.

Да дофига от чего зависит.
В боевой базе одной весьма популярной в РФ ММОРПГ вообще нет вторичных ключей. Т.е. вот совсем. Нету. И денормализована сильно.

> Ну, для подобного - да, а для "кошек" видимо, опять заводить
> таблицу с их мастью..

Ну да, она пригодится и для собак. Кто знает что захочет юзер завтра? :)

Спасибо, AV!..

> MonoLife (28.09.2012 12:26:27) [27]

И это тоже полезно, прогуляешься, проветришься.

> MonoLife (28.09.2012 12:53:32) [32]

Я же говорил депресант

> Anatoly Podgoretsky © (28.09.12 12:23) [26]
> > Anatoly Podgoretsky (28.09.2012 12:23:25) [25]
>
> Кофе хороший депресант

И великолепное противозачаточное

> И великолепное противозачаточное

Блин, чего тут только не узнаешь :)
Хорошо, что я его не совсем пью и подруг проверяю на запах кофе :)

> Блин, чего тут только не узнаешь :)

это точно!)

> Хорошо, что я его не совсем пью...

до половины...)

> [34] Павел Калугин © (28.09.12 12:57)
> И великолепное противозачаточное

Механизм действия? И куда/как его надо употребить для этого? Снижает эрекцию, имеет угнетающе-снотворное действие на ЦНС, расширяет сознание до размеров не совместимых с истинктами размножения? Вроде нет. Только один способ приходит на ум - обмакнуть в чашку с только что сваренным кофе.

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

> Inovet © (28.09.12 13:30) [37]

это, наверное, анек
Старый профессор, желая подогреть интерес к лекциям, сказал, что на одной из них расскажет как дешево и 100%% не забеременеть. Ну, посещаемость, конечно 100%%, все ждут.. Последняя лекция в году, профессор заканчивает выступать, собирается домой..
Все: ????!!!!
Профессор: А.. да.. насчет не забеременеть.. Чай пейте!
Все: Какой, как.. И до или после?!
Профессор: Вместо!

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

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

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