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

← →
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 © (2012-09-28 12:43) [29]

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

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

← →
MonoLife © (2012-09-28 12:46) [30]

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

← →
Anatoly Podgoretsky © (2012-09-28 12:46) [31]

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

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

← →
MonoLife © (2012-09-28 12:53) [32]

> Anatoly Podgoretsky © (28.09.12 12:46) [31]

гулять и проветриваться - всегда пожалуйста)

← →
Anatoly Podgoretsky © (2012-09-28 12:54) [33]

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

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

← →
Павел Калугин © (2012-09-28 12:57) [34]

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

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

← →
Jeer © (2012-09-28 13:03) [35]

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

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

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

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

это точно!)

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

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

← →
Inovet © (2012-09-28 13:30) [37]

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

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

← →
Inovet © (2012-09-28 13:32) [38]

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

← →
AV © (2012-09-28 13:34) [39]

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

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

← →
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]

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

← →
MonoLife © (2012-09-28 16:06) [69]

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

пожалуй, да

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

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

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

← →
vuk © (2012-09-28 16:22) [71]

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

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

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

← →
MsGuns © (2012-09-28 16:41) [72]

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

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

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

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

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

vuk © (28.09.12 16:22) [71]

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

← →
MonoLife © (2012-09-28 16:55) [74]

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

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

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

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

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

← →
vuk © (2012-09-28 17:04) [76]

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

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

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

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

← →
Anatoly Podgoretsky © (2012-09-28 19:48) [77]

> MonoLife © (28.09.12 16:55) [74]

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

← →
vuk © (2012-09-29 13:57) [78]

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

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

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

← →
Kerk © (2012-09-29 16:16) [79]

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

← →
Jeer © (2012-09-29 16:33) [80]

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

← →
Inovet © (2012-09-29 16:35) [81]

> [79] Kerk © (29.09.12 16:16)

Ешё кирилица сказывается, при транслитерации длинно бывает и кто во что горазд, ещё и смешно иногда.

← →
Inovet © (2012-09-29 16:36) [82]

> [81] Inovet © (29.09.12 16:35)

Хотя немцы по длинне своих конструкций не коплексуют.

← →
Kerk © (2012-09-29 16:54) [83]

> Inovet © (29.09.12 16:36) [82]

Не, не комплексуют.
Мониторы сейчас широкие, диски большие, смысл буквы экономить? :)

← →
Kerk © (2012-09-29 16:54) [84]

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

← →
Jeer © (2012-09-29 17:59) [85]

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

← →
Jeer © (2012-09-29 18:00) [86]

> смысл буквы экономить? :)

Чтобы по-меньше словоблудить.

← →
Kerk © (2012-09-29 18:04) [87]

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

← →
Jeer © (2012-09-29 18:15) [88]

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

← →
turbouser © (2012-09-29 21:50) [89]

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

← →
asail © (2012-09-29 22:11) [90]

> Kerk © (29.09.12 16:16) [79]

> Хотя таблицы или пакеты названные по-немецки -- обыденность.

Это тоже - фу-фу-фу. На мой провинциальный взгляд, конечно...

← →
Kerk © (2012-09-29 22:44) [91]

> asail © (29.09.12 22:11) [90]

По-моему, все хорошо, когда к месту. Когда старательно пишут по-английски в стиле "MGIMO finished", хотя сразу понятно, что никто нерусскоязычный этот код никогда не увидит... Не факт, что это меньшее фу-фу-фу.

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

← →
Kerk © (2012-09-29 22:50) [92]

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

← →
no_way (2012-09-29 22:57) [93]

> Чем оно им плохо?

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

← →
Kerk © (2012-09-29 23:10) [94]

no_way, большинство проектов никогда не будут переданы заграницу, мы же все это понимаем.

← →
no_way (2012-09-29 23:22) [95]

> Kerk © (29.09.12 23:10) [94]

большинство - это что?
те которые делаются дома?
или те за которые таки деньги платят?
так и те, и те имеют шансы быть передаными
первые, например, быть форкнутыми с гитхаба
вторые - начальство захотело

мне просто часто приходится сталкиваться в силу моей "фриланской" работы

← →
Kerk © (2012-09-29 23:34) [96]

Если я правильно тебя узнал, ты до своей фрилансерской работы работал по-моему на заводе или типа того. Вот такие проекты местной автоматизации не отдаются никуда. И таких проектов очень много, если не большинство.

← →
no_way (2012-09-29 23:42) [97]

> Если я правильно тебя узнал

правильно :-)

> на заводе или типа того

много где, завод просто последнее было на дядю

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

они нах никому не нужны, в том числе самим заводам
после моего увольнения через год-полтора "внедрили" sap и все старые разработки почти сразу в мусорку пошли

← →
Kerk © (2012-09-30 00:54) [98]

> no_way (29.09.12 23:42) [97]

Вот видишь, никому бы не было хуже, если б вы таблицы назвали по-немецки :))

← →
asail © (2012-09-30 01:07) [99]

> Kerk © (29.09.12 22:50) [92]
> Ты вот кстати аргументировал бы почему таблица называнная
> по-немецки -- это фу-фу-фу?

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

← →
no_way (2012-09-30 01:45) [100]

> Вот видишь, никому бы не было хуже, если б вы таблицы назвали
> по-немецки :))

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

← →
vuk © (2012-09-30 10:14) [101]

to Kerk © (29.09.12 16:16) [79]:

> В плане догм интересный момент заметил с именованием таблиц
> и т.п. У нас называть объекты БД по-русски -- фу-фу-фу.
> Хотя таблицы или пакеты названные по-немецки -- обыденность.
>

А это надо смотреть, во что это выливается по переключению клавиатурных раскладок. :)

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

Kerk © (29.09.12 16:16) [79]

> Хотя таблицы или пакеты названные по-немецки -- обыденность

а скажи, со всеми символами немецкого алфавита, отсутствующими в английском или таки с подмножеством символов, присутствующем в обоих алфавитах ?

← →
Kerk © (2012-09-30 12:26) [103]

> asail © (30.09.12 01:07) [99]

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

Ну неужто только я видел проекты, которые никогда никуда не будут переданы? Не потому, что они какие-то плохие, а потому что специфика такая у них, местная. Ну не верю, что я единственный, кто их видел.

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

> Игорь Шевченко © (30.09.12 11:16) [102]
>
> Kerk © (29.09.12 16:16) [79]
>
> > Хотя таблицы или пакеты названные по-немецки -- обыденность
>
> а скажи, со всеми символами немецкого алфавита, отсутствующими
> в английском или таки с подмножеством символов, присутствующем
> в обоих алфавитах ?

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

Кстати, можно еще похоливорить о (не)богоугодности quoted-имен в Oracle. Вот уж где засада.

Как-то лет 10 назад читал в конфе по FB про немцев, которые всё именовали по-немецки и каждое имя педантично заключали в кавычки.

> Подмножеством, насколько я успел заменить. Сам я не говорю
> по-немецки, как ты понимаешь, но всяких умляутов вроде не
> видел

Ну так это то же самое, что транслитерация названий объектов по-русски. Еще Жанна Зайцева в своей книге по ассемблеру ЕС ЭВМ такое использовала. (Это типа Архангелького такая авторша)

> Kerk © (30.09.12 12:26) [103]

> Ну неужто только я видел проекты, которые никогда никуда
> не будут переданы?

Да видел я такие проекты, видел... Но, зачем же изначально загонять себя в узкие рамки? Может, потом и не весь проект, а какую его часть захочется перенести во что-то глобальное? А тут такая засада и хоть пиши все с нуля. Зачем?
А юникод тож не панацея... Ну, назвал ты поле КОЛЛИЧЕСТВО. А первые две буквы оказались набранны в латинице. Потом при попытке написать на это запрос твой коллега будет долго за тобой по оффису гоняться с чем-то тяжелым в руках... :)
З.Ы. еще одно преимущество англицкого - лаконичность. В этом плане и немецкий и русский сильно уступают... Тады уж лучше китайский или иврит, чес слово.

Ну ОК, я не настаиваю. Просто заметил, что фу-фу-фу - слишком резкая реакция :)

Резюмирую. По умолчанию все объекты следует называть по-английски, а для именования на русском/немецком/китайском должны быть веские причины, например:
1) требование называть объекты на русском/немецком/китайском включено в ТЗ
2) разработка на русском/немецком/китайском языке программирования (типа 1С)
3) 100% уверенность, что проект всегда будет разрабатываться только русскими/немецкими/китайскими разработчиками (обычно приводит к пункту 1)
4) незнание английского (даже со словарем) разработчиками
5) ненависть к английскому (часто вызвана пунктом 4 или приводит к пункту 4)

> Компромисс © (01.10.12 09:41) [109]
> а для именования на русском/немецком/китайском должны быть
> веские причины, например:

добавить "транслитерацией" или на русском/ ...и т.п.

> 3) 100% уверенность, что проект всегда будет разрабатываться
> только русскими/немецкими/китайскими разработчиками (обычно
> приводит к пункту 1)

Откуда взялось это "обычно" совершенно не ясно. В остальном именно так.

Давайте уже признаем, что де-факто сложилась традиция, когда стандартом в программировании является английский язык.
Так же, как x,y,z - координаты в декартовом пространстве. Так же, как i,j,k - счётчики цикла. Так же, как Foo и Bar. И т.д.
Тупо традиция, не более того.

не, не совсем удобны национализмы :)
когда разбирая код, попадается
create or replace function ZAYAVKA_CHECK_STATUS
("смешение французского с нижегородским")
доверие к возвращаемому как-то падает ..

Да пофигу как.

ega23 (13:20:06 1/10/2012)
Но если я вижу write или read - мне интуитивно понятно, что тут происходит.
ega23 (13:20:41 1/10/2012)
А если я увижу pisat и chitat - меня это в некоторый ступор вгонит.
ega23 (13:20:52 1/10/2012)
Ненадолго, но вгонит.

Бывает страшнее, когда вроде бы всем понятное работает не так, как предполагаешь.

TSomeClass = class private function GetFoo: TFoo; function GetFooEx: TFoo; procedure SetFoo(Value: TFoo); procedure SetFooEx(Value: TFoo); public property Foo: TFoo read GetFooEx write SetFooEx; end;

Интуитивно ищешь геттер и сеттер с именем GetFoo и SetFoo. А оно вообще не так работает и отладчик туда не заходит. И только потом доходит, что оказывается это совсем не то, что предполагалось.
(А если ещё и inline проставить, то вообще бидапичать, отладчик не сработает).

Пешыте так, как понятно всем, и будет щщасте.

> Ну да. Но, на такое, вообще-то, компилятор варнингом в лицо плюется...

Delphi 2010, никаких варнингов:

TSomeClass = class private FFoo: TFoo; function GetFoo: TFoo; function GetFooEx: TFoo; procedure SetFoo(Value: TFoo); procedure SetFooEx(Value: TFoo); public constructor Create; property Foo: TFoo read GetFooEx write SetFooEx; end; { TSomeClass } constructor TSomeClass.Create; begin GetFoo; SetFoo(1); end; function TSomeClass.GetFoo: TFoo; begin Result := FFoo; end; function TSomeClass.GetFooEx: TFoo; begin Result := FFoo; end; procedure TSomeClass.SetFoo(Value: TFoo); begin FFoo := Value; end; procedure TSomeClass.SetFooEx(Value: TFoo); begin FFoo := Value; end;

> на такое, вообще-то, компилятор варнингом в лицо плюется.
> ..

С чего бы ?
Тут вопрос сходного наименования одинаковых методов, компилятору это все рано.

вот, даже в "тестовом" примере asail попался на невнимательность :)
что уж говорить про разбор реального кода

а еще можно в стиле "define True = False" написать
property Foo: TFoo read SetFooEx write Create;
ваще крышу сорвет :)

> property Foo: TFoo read SetFooEx write Create;
> ваще крышу сорвет :)

Ну да.

TSomeClass = class
private
procedure Create(Value: TFoo); overload;
public
constructor SetFoo;
class procedure Create; overload;
property Foo: TFoo read GetFoo write Create;
end;

Что-то типа этого... :)))

to AV © (01.10.12 17:30) [119]:

> а еще можно в стиле "define True = False" написать property
> Foo: TFoo read SetFooEx write Create;ваще крышу сорвет :
> )

Тока последовательность перепутана. Сначала - крышу, и только потом уже - написать.

> Ega23 © (01.10.12 16:25) [117]

> Delphi 2010, никаких варнингов:

Это потому, что ты смухлевал... Убери вызов неиспользуемых геттера и сеттера из конструктора и будет тебе счастие! :)
Кстати, так это напоминает индусскую попытку от этих самых варнингов избавиться. Я такое уже видел, только там компактней записали - в одну строчку: SetSomething(GetSomething). :)

> AV © (01.10.12 17:30) [119]
> вот, даже в "тестовом" примере asail попался на невнимательность
> :)

В чем конкретно "попался"?

> Это потому, что ты смухлевал... Убери вызов неиспользуемых
> геттера и сеттера из конструктора и будет тебе счастие!
> :)

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

> Убери вызов неиспользуемых геттера и сеттера из конструктора
> и будет тебе счастие! :)

Ну и если уж на то пошло, то, во-первых, они вовсе не геттер и сеттер, а во-вторых - их достаточно в public перенести.

> Ega23 © (01.10.12 22:38) [123]

> показал пример кода, в котором геттер и сеттер были обозваны
> не так, как привычно

Это понятно.

> естественно данные методы использовались

А вот это уже нет. Из примера не видно. Отсюда и моя ремарка про варнинги. И всего делов.

> Ega23 © (01.10.12 23:12) [124]

> Ну и если уж на то пошло

В-третьих, они могли оказаться геттером и сеттором для какого-то другого свойтства. А можно еще и в-четвертых и в-пятых придумать... Только зачем? :)

> А вот это уже нет. Из примера не видно.

Кому надо - тот увидел.

> Отсюда и моя ремарка про варнинги.

> В чем конкретно "попался"?

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

Кстати по сабжу.. А не так все просто оказалось :) Автор хитер :)
я сделал эмуляцию, в реляциях, получилось довольно плохо.

> Тупо традиция, не более того.

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

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

Да и Ритчи наверняка не ариец...

> AV © (02.10.12 08:45) [127]

> Да нет там варгнингов, и быть не может

Может. См. ниже...

> Методы названы в пределах правил

Хто бы спорил... Тут вопросов нет.

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

А вот тут ошибаешься. Сокрытие тут не причем. Я про другой варнинг говорил - о неиспользуемом privet методе. Вот, Олег понял, потому и добавил вызов этих самых методов в конструкторе в своем следующем посте...

> Вот, Олег понял, потому и добавил вызов этих самых методов
> в конструкторе в своем следующем посте...

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

> Ega23 © (02.10.12 14:52) [133]

> Олег понял, что кое-кому заняться нечем, кроме придирок

Да где ж ты там придирки-то увидел?

> Да где ж ты там придирки-то увидел?

А где ты там увидел варнинги?

> Ega23 © (02.10.12 14:58) [135]

Я в приведенном тобой примере увидел следующее:
1. Для свойства Foo были назначенны сеттер и геттер SetFooEx и GetFooEx.
2. Учитывая, что более привычные SetFoo и GetFoo остались в коде, я предположил, что они просто были заменены теми, что Ex.
3. Соответственно, можно было предположить, что старые методы перестали использоваться.
4. И, соответственно, должен был быть варнинг о двух не использующихся приват-методах.

Понятно, что все могло быть и не совсем так, но мне приведенный выше сценарий показался наиболее логичным.
Особенно, учитывая, что я такое в реале видел в исполнении индусов. И заглушили они там эти варнинги именно тем самым способом, что и у тебя в [117] - бесполезным вызовом в конструкторе... :)

> Понятно, что все могло быть и не совсем так, но мне приведенный
> выше сценарий показался наиболее логичным.

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

> Ega23 © (02.10.12 16:26) [137]

> Если бы ты прочитал то, что написано после этого кода, то
> не строил бы предположений.

А я прочитал. И фраза о том, что отладчик не заходит в SetFoo и GetFoo только укрепила мое предположение, что они не используются...

> Эмуляция в конструкторе - мне просто лень было писать код

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

> И фраза о том, что отладчик не заходит в SetFoo и GetFoo
> только укрепила мое предположение, что они не используются.

Они - используются. Если тебе так стрёмнор - перенеси их в паблик и успокойся уже.

> Ega23 © (02.10.12 16:41) [139]

> Они - используются.

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

> перенеси их в паблик

Зачем дурное советуешь, а? :)

> Зачем дурное советуешь, а?

Обоснуй.

> Обоснуй.

А нафига они в паблике? Давай я немного перефразирую этот вопрос - а нафига эти два метода были вообще внесены в твой тестовый пример? С какой целью? Я так понимаю, чтоб запутать где чей геттер/сеттер... А если бы они были бы в паблике, то пример стал бы гораздо более прозрачным, и тебе бы не пришлось "Интуитивно искать геттер и сеттер с именем GetFoo и SetFoo". Сразу бы наткнулся на Ех... Бо, геттеры и сеттеры обычно в паблик не пихают... Ну, разве только в случае класса, реализующего интерфейс.

Начнём с конца.

> Ну, разве только в случае класса, реализующего интерфейс.

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

> Бо, геттеры и сеттеры обычно в паблик не пихают

Ключевое слово - обычно. У меня же рассматривался не обычный пример. Мне никто не мешает обозвать геттер именем SaveToStream, а процедуру сериализации - GetItem.
Вообще никто (ну если я не в команде работаю). Как хочу, так и обзываю.
Где это дело будет стоять - опять же мои половые проблемы. Возможно я понятия не имею про инкапсуляцию, я вообще сторонник максимально открытого кода и у меня все поля и методы - в published сидят :) .
Но вот тому, кто потом такой код разбирать будет, я не позавидую.

> Давай я немного перефразирую этот вопрос - а нафига эти
> два метода были вообще внесены в твой тестовый пример?

Ты издеваешься? Я просто устал уже объяснять. Это не тестовый пример. Это вообще набросок маленькой части кода, с которой я столкнулся. Где метод с привычным именем для свойства Items GetItem выполнял не помню уже что. А реальный геттер свойства Items был GetChild (вроде).

> Я так понимаю, чтоб запутать где чей геттер/сеттер...

Не так понимаешь. Впрочем я уже выше всё написал. Кому надо - тот понял.

> Ega23 © (02.10.12 19:31) [143]

Я уже писал - согласен, что варнинга может и не быть. В том виде, в котором ты его привел, он должен был быть. Телепатор пошел по наиболее простому и очевидному пути (см [136] и [138])... Потом ты говоришь, что там все не так просто было, как в приведенном куске кода. Ну да, тогда все что угодно может быть - и варнинги, и ошибки компиляции, и ни того и ни другого.
Чего взъелся-то? :)

По сабжу:
Задача проектирования хранилища для произвольной таксономии не очень хорошо согласуется с реляционной моделью. Может быть стоит смотреть в сторону графоописывающих СУБД типа HyperGraphDB?

Правда, нам в свое время пришлось отказаться от гиперграфа.

> не очень хорошо согласуется с реляционной моделью

Видимо, да..

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