|
|
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Есть квартиры. В каждой квартире есть всякие удобства, например 1. Холодильник 2. Стиральная машина 3. Мебель 4. Микроволновка и т.д. - всего таких позиций может быть до 15. На каждой странице сайта планируется показывать что из этого есть, а чего из этого нету. Например 1. Холодильник - да 2. Стиральная машина - нет 3. Мебель - да 4. Микроволновка - нет Вопрос, как хранить эти значения в базе? Я так понимаю есть два варианта 1. Создается таблица с полями под каждый атрибут и имеет либо Null либо 1 Apartments id, holodilnik, stirmashina, mebel, mikrovolnovka 1 1 null 1 null 2 null 1 null 1 2. Создаются 2 таблицы. Atributi id, nazvanie_atributa 1. Холодильник 2. Стиральная машина 3. Мебель 4. Микроволновка Atributi_v_Kvartirah id_kvartiri, id_atrubuta 1 1 1 2 1 3 2 1 Какой вариант будет меньше нагружать базу? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2013, 17:45 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
NekifrovvКакой вариант будет меньше нагружать базу? Второй. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2013, 17:51 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Первый способ однозначно быстрее и проще, плюс по занимаемому месту хранения как миминум не хуже ибо null места почти не занимает, но у него есть существенный недостаток. Опыт показывает что всего таких позиций может быть до 15 это вас обманули. Чем дальше развивается система тем больше становится таких позиций. А каждое добавление поля это DDL, отдельный патч на базу и приложение и прочий гемор. Плюс в СУБД может существовать ограничение на количество таблиц и т.д. В общем я голосую за второй вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2013, 21:40 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
NekifrovvКакой вариант будет меньше нагружать базу? Спасибо. Надо проектировать БД не так, чтобы её меньше нагружать, а так, чтобы она была правильной, не было бы аномалий. Потому что БД должна сначала работать, а потом работать быстро. Твой первый вариант -- нарушение 1НФ. Второй -- нормальный. Значит, надо делать по второму варианту. автори т.д. - всего таких позиций может быть до 15. Вот это тут главная ошибка. В реляционных БД не бывает "до 15". Либо 1, либо много, от 0 до бесконечности. Второй вариант этому удовлетворяет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 12:32 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
SERG1257Первый способ однозначно быстрее и проще, плюс по занимаемому месту хранения как миминум не хуже ибо null места почти не занимает, но у него есть существенный недостаток. Опыт показывает что всего таких позиций может быть до 15 это вас обманули. Чем дальше развивается система тем больше становится таких позиций. А каждое добавление поля это DDL, отдельный патч на базу и приложение и прочий гемор. Плюс в СУБД может существовать ограничение на количество таблиц и т.д. В общем я голосую за второй вариант. Первый способ неприемлим. Это нарушение 1НФ. Будет очень непросто формировать запросы на такую структуру, она нерегулярна. Вторая -- наоборот, всё просто и легко. А производительность будет диктоваться наличием нужных индексов, они тут по построению все есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 12:34 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZivSERG1257Первый способ однозначно быстрее и проще, плюс по занимаемому месту хранения как миминум не хуже ибо null места почти не занимает, но у него есть существенный недостаток. Опыт показывает что всего таких позиций может быть до 15 это вас обманули. Чем дальше развивается система тем больше становится таких позиций. А каждое добавление поля это DDL, отдельный патч на базу и приложение и прочий гемор. Плюс в СУБД может существовать ограничение на количество таблиц и т.д. В общем я голосую за второй вариант. Первый способ неприемлим. Это нарушение 1НФ. Каким боком тут нарушение 1НФ? Какой атрибут в схеме неатомарен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 12:43 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинMasterZivпропущено... Первый способ неприемлим. Это нарушение 1НФ. Каким боком тут нарушение 1НФ? Какой атрибут в схеме неатомарен? автори т.д. - всего таких позиций может быть до 15. На каждой странице сайта планируется показывать что из этого есть, а чего из этого нету. Например Вот это и неатомарно. Это массив из свойств квартиры размером до 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 14:39 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Всем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 16:15 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZivКот Матроскинпропущено... Каким боком тут нарушение 1НФ? Какой атрибут в схеме неатомарен? автори т.д. - всего таких позиций может быть до 15. На каждой странице сайта планируется показывать что из этого есть, а чего из этого нету. Например Вот это и неатомарно. Это массив из свойств квартиры размером до 15. Что "это"? Для нарушения 1НФ в отношении должен быть неатомарный атрибут . В варианте же предлагается пачка совершенно атомарных независимых атрибутов. Обсуждаемый вариант - в общем случае плохой, с этим никто не спорит. Но нормализация тут не при чем, он плох не поэтому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 18:08 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZivВот это и неатомарно. Это массив из свойств квартиры размером до 15. Никакой это не массив. Вот если бы ТС впихнул все это в одно поле, например, в виде строки "0010011001", или битовой маски, и условился о соответствии "номер позиции<->вид удобства", это было бы нарушение 1НФ в чистом виде. А так это скорее вопрос правильного выделения сущностей. Является ли наличие холодильника атрибутом квартиры, или есть отдельная сущность "Удобства", одним из значений которой является "Холодильник"? Для ответа можно подумать, например, есть ли у холодильника, стиралки и т.д. свои атрибуты. Если есть - это, конечно, сущности: объем холодильника, вместимость стиралки и т.д, и надо делать отдельную таблицу. А если нет - то, возможно, все же логические атрибуты квартиры. Второй вопрос - будет ли этих удобств бесконечное множество, или все-таки 15. ТС говорит об ограниченности количества. Короче, в простейшем примере, приведенном ТС, недостаточно аргументов для решающего выбора, так что и первый вариант выглядит приемлемым. Единственный аргумент в пользу второго - "а вдруг": "вдруг удобств станет много", "вдруг у них появятся свои атрибуты", "опыт показывает, что вдруг так и бывает". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 11:50 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
NekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии. Добро пожаловать в мир EAV. Для примера, простейший запрос: "Выбрать квартиры, где есть холодильник и стиралка, но нет ни мебели, ни микроволновки". Составьте для первого и второго варианта, сравните. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 11:54 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинMasterZivпропущено... пропущено... Вот это и неатомарно. Это массив из свойств квартиры размером до 15. Что "это"? Для нарушения 1НФ в отношении должен быть неатомарный атрибут . В варианте же предлагается пачка совершенно атомарных независимых атрибутов. Обсуждаемый вариант - в общем случае плохой, с этим никто не спорит. Но нормализация тут не при чем, он плох не поэтому. При чем, при чем. Это именно он и есть. Неатомарный атрибут. Из 15 полей. Задай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 11:59 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher, Это и есть массив, других массивов в рсубд нет и быть не может. Это набор полей, служащих одному назначению в предметной области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 12:02 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherNekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии. Добро пожаловать в мир EAV. Для примера, простейший запрос: "Выбрать квартиры, где есть холодильник и стиралка, но нет ни мебели, ни микроволновки". Составьте для первого и второго варианта, сравните. EAV тут ни при чем, это стандартная классика пока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 12:03 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Cane Cat Никакой это не массив. Вот если бы ТС впихнул все это в одно поле, например, в виде строки "0010011001", или битовой маски, и условился о соответствии "номер позиции<->вид удобства", это было бы нарушение 1НФ в чистом виде. Ха, а какая принципиальная разница между этим решением и приведенным автором топика ? Ответь себе на этот вопрос и может ты поймешь, почему ты неправ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 12:07 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Боюсь, Вы не понимаете, что такое нормализация и какие задачи она решает. MasterZivЗадай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь. "Получить свойства квартиры в виде списка " - это, грубо говоря, выходная форма. Проектировать БД исходя из выходных форм - плохая практика. Завтра Вас попросят "выдайте нам свойства квартиры одной строкой" - Вы будете переделывать схему данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 12:22 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто и есть массив, других массивов в рсубд нет и быть не может. Это набор полей, служащих одному назначению в предметной области. Фамилия, Имя, Отчество в одной таблице - это тоже массив, и нарушение 1НФ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 12:25 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZivНеатомарный атрибут. Из 15 полей. Любопытная логика. А в виде 15 записей, этот "атрибут", стало быть, атомарный? :-) MasterZivЗадай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь. Такими вопросами можно всю святость свести к все таблицы по вертикали развернуть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 12:34 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherMasterZivЭто и есть массив, других массивов в рсубд нет и быть не может. Это набор полей, служащих одному назначению в предметной области. Фамилия, Имя, Отчество в одной таблице - это тоже массив, и нарушение 1НФ ? Нет, это разные атрибуты, у них назначение разное. Одно -- фамилия, другое -- имя, третье -- отчество. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 13:39 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинMasterZiv, Боюсь, Вы не понимаете, что такое нормализация и какие задачи она решает. MasterZivЗадай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь. "Получить свойства квартиры в виде списка " - это, грубо говоря, выходная форма. Проектировать БД исходя из выходных форм - плохая практика. Завтра Вас попросят "выдайте нам свойства квартиры одной строкой" - Вы будете переделывать схему данных? Это запрос, который надо написать. Какая выходная форма ? Кортежи надо получить, где было бы (Квартира, свойство) Все свойства, что есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 13:52 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто запрос, который надо написать. Какая выходная форма ? Кортежи надо получить, где было бы (Квартира, свойство) Все свойства, что есть. Еще раз - это неправильная логика, аргументировать схему данных "а вот такой [взятый с потолка] запрос писать проще!" (и уж совершенно точно эта логика не имеет отношения к нормализации, на которую Вы напирали). Если потребуется написать запрос (квартира, свойство1, свойство2,...свойство15) - Вы будете переделывать схему данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 14:19 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
> победил второй вариант. Посмотрим, как он покажет себя в действии. Обычно сначала тестируют, а потом объявляют о победе. Видите ли, безобразно кривы оба предложенных вами варианта. Особенность в том, что задача и не предполагает не кривых решений. На вашем месте я бы остановился на первом варианте: просто, дёшево, сердито. При необходимости добавить раз в полгода пару полей - не проблема. Только замените в таблице 1/NULL на true/false. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 14:32 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
MasterZivНет, это разные атрибуты, у них назначение разное. Одно -- фамилия, другое -- имя, третье -- отчество. Глубина открытия потрясает. Мне кажется, что между холодильником и стиралкой все же больше разницы. По крайней мере, они не взаимозаменяемы. А ФИО - запросто: в садике всех зовут по именам, в армии - по фамилиям, на пенсии - по отчествам. Чем не "набор полей, служащих одному назначению в предметной области" ? Просто формальная кривость первого варианта вовсе не в нарушении 1НФ, а в эмпирическом правиле "избегайте индексированных атрибутов". Я не поленился перелистать Дейта, но в формальном виде этого правила не нашел, помню только у обкуренного Джо Селко. Может, кто-то укажет на формальное определение недостатка первого варианта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 17:17 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher, Я уже указывал, формально это нарушение 1НФ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 09:56 |
|
||
|
Подскажите на конктретном примере
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherNekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии. Добро пожаловать в мир EAV. Для примера, простейший запрос: "Выбрать квартиры, где есть холодильник и стиралка, но нет ни мебели, ни микроволновки". Составьте для первого и второго варианта, сравните. А Вы, в свою очередь, составьте этот запрос для совершенно правильного Вашего варианта из 15013211 который Вы ошибочно раскритиковали - 1НФ в нем не нарушается никак. И даже после того, как добавят материальный учет, так сказать (конечно, клиентов будет интересовать объем холодильника), то это (тогда - уже вычисляемое) поле вполне может использоваться. Второй вариант не имеет вообще никакого отношения к БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 20:19 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38436859&tid=1541071]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 132ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...