powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите на конктретном примере
25 сообщений из 66, страница 1 из 3
Подскажите на конктретном примере
    #38434659
Nekifrovv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть квартиры. В каждой квартире есть всякие удобства, например

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


Какой вариант будет меньше нагружать базу? Спасибо.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38434662
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekifrovvКакой вариант будет меньше нагружать базу?
Второй.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38434803
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Первый способ однозначно быстрее и проще, плюс по занимаемому месту хранения как миминум не хуже ибо null места почти не занимает, но у него есть существенный недостаток. Опыт показывает что всего таких позиций может быть до 15 это вас обманули. Чем дальше развивается система тем больше становится таких позиций. А каждое добавление поля это DDL, отдельный патч на базу и приложение и прочий гемор. Плюс в СУБД может существовать ограничение на количество таблиц и т.д.
В общем я голосую за второй вариант.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38435319
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekifrovvКакой вариант будет меньше нагружать базу? Спасибо.

Надо проектировать БД не так, чтобы её меньше нагружать, а так, чтобы она была правильной, не было бы аномалий.
Потому что БД должна сначала работать, а потом работать быстро.

Твой первый вариант -- нарушение 1НФ. Второй -- нормальный. Значит, надо делать по второму варианту.

автори т.д. - всего таких позиций может быть до 15.


Вот это тут главная ошибка. В реляционных БД не бывает "до 15". Либо 1, либо много, от 0 до бесконечности.
Второй вариант этому удовлетворяет.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38435323
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Первый способ однозначно быстрее и проще, плюс по занимаемому месту хранения как миминум не хуже ибо null места почти не занимает, но у него есть существенный недостаток. Опыт показывает что всего таких позиций может быть до 15 это вас обманули. Чем дальше развивается система тем больше становится таких позиций. А каждое добавление поля это DDL, отдельный патч на базу и приложение и прочий гемор. Плюс в СУБД может существовать ограничение на количество таблиц и т.д.
В общем я голосую за второй вариант.

Первый способ неприемлим. Это нарушение 1НФ.
Будет очень непросто формировать запросы на такую структуру, она нерегулярна.
Вторая -- наоборот, всё просто и легко.

А производительность будет диктоваться наличием нужных индексов, они тут по построению все есть.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38435338
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivSERG1257Первый способ однозначно быстрее и проще, плюс по занимаемому месту хранения как миминум не хуже ибо null места почти не занимает, но у него есть существенный недостаток. Опыт показывает что всего таких позиций может быть до 15 это вас обманули. Чем дальше развивается система тем больше становится таких позиций. А каждое добавление поля это DDL, отдельный патч на базу и приложение и прочий гемор. Плюс в СУБД может существовать ограничение на количество таблиц и т.д.
В общем я голосую за второй вариант.

Первый способ неприемлим. Это нарушение 1НФ.

Каким боком тут нарушение 1НФ? Какой атрибут в схеме неатомарен?
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38435574
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинMasterZivпропущено...


Первый способ неприемлим. Это нарушение 1НФ.

Каким боком тут нарушение 1НФ? Какой атрибут в схеме неатомарен?


автори т.д. - всего таких позиций может быть до 15.

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

Вот это и неатомарно. Это массив из свойств квартиры размером до 15.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38435767
Nekifrovv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38435992
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivКот Матроскинпропущено...

Каким боком тут нарушение 1НФ? Какой атрибут в схеме неатомарен?


автори т.д. - всего таких позиций может быть до 15.

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

Вот это и неатомарно. Это массив из свойств квартиры размером до 15.

Что "это"? Для нарушения 1НФ в отношении должен быть неатомарный атрибут . В варианте же предлагается пачка совершенно атомарных независимых атрибутов.
Обсуждаемый вариант - в общем случае плохой, с этим никто не спорит. Но нормализация тут не при чем, он плох не поэтому.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436612
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivВот это и неатомарно. Это массив из свойств квартиры размером до 15.

Никакой это не массив. Вот если бы ТС впихнул все это в одно поле, например, в виде строки "0010011001", или битовой маски, и условился о соответствии "номер позиции<->вид удобства", это было бы нарушение 1НФ в чистом виде. А так это скорее вопрос правильного выделения сущностей. Является ли наличие холодильника атрибутом квартиры, или есть отдельная сущность "Удобства", одним из значений которой является "Холодильник"?

Для ответа можно подумать, например, есть ли у холодильника, стиралки и т.д. свои атрибуты. Если есть - это, конечно, сущности: объем холодильника, вместимость стиралки и т.д, и надо делать отдельную таблицу. А если нет - то, возможно, все же логические атрибуты квартиры.

Второй вопрос - будет ли этих удобств бесконечное множество, или все-таки 15. ТС говорит об ограниченности количества.

Короче, в простейшем примере, приведенном ТС, недостаточно аргументов для решающего выбора, так что и первый вариант выглядит приемлемым. Единственный аргумент в пользу второго - "а вдруг": "вдруг удобств станет много", "вдруг у них появятся свои атрибуты", "опыт показывает, что вдруг так и бывает".
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436620
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии.

Добро пожаловать в мир EAV. Для примера, простейший запрос: "Выбрать квартиры, где есть холодильник и стиралка, но нет ни мебели, ни микроволновки". Составьте для первого и второго варианта, сравните.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436630
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинMasterZivпропущено...



пропущено...


Вот это и неатомарно. Это массив из свойств квартиры размером до 15.

Что "это"? Для нарушения 1НФ в отношении должен быть неатомарный атрибут . В варианте же предлагается пачка совершенно атомарных независимых атрибутов.
Обсуждаемый вариант - в общем случае плохой, с этим никто не спорит. Но нормализация тут не при чем, он плох не поэтому.

При чем, при чем. Это именно он и есть.
Неатомарный атрибут. Из 15 полей.

Задай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436634
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cane Cat Fisher,

Это и есть массив, других массивов в рсубд нет и быть не может.
Это набор полей, служащих одному назначению в предметной области.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436637
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cane Cat FisherNekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии.

Добро пожаловать в мир EAV. Для примера, простейший запрос: "Выбрать квартиры, где есть холодильник и стиралка, но нет ни мебели, ни микроволновки". Составьте для первого и второго варианта, сравните.

EAV тут ни при чем, это стандартная классика пока.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436645
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cane Cat

Никакой это не массив. Вот если бы ТС впихнул все это в одно поле, например, в виде строки "0010011001", или битовой маски, и условился о соответствии "номер позиции<->вид удобства", это было бы нарушение 1НФ в чистом виде.

Ха, а какая принципиальная разница между этим решением и приведенным автором топика ? Ответь себе на этот вопрос и может ты поймешь, почему ты неправ...
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436671
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,

Боюсь, Вы не понимаете, что такое нормализация и какие задачи она решает.

MasterZivЗадай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь.
"Получить свойства квартиры в виде списка " - это, грубо говоря, выходная форма. Проектировать БД исходя из выходных форм - плохая практика. Завтра Вас попросят "выдайте нам свойства квартиры одной строкой" - Вы будете переделывать схему данных?
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436677
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivЭто и есть массив, других массивов в рсубд нет и быть не может.
Это набор полей, служащих одному назначению в предметной области.

Фамилия, Имя, Отчество в одной таблице - это тоже массив, и нарушение 1НФ ?
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436706
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivНеатомарный атрибут. Из 15 полей.
Любопытная логика. А в виде 15 записей, этот "атрибут", стало быть, атомарный? :-)

MasterZivЗадай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь.
Такими вопросами можно всю святость свести к все таблицы по вертикали развернуть.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436859
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cane Cat FisherMasterZivЭто и есть массив, других массивов в рсубд нет и быть не может.
Это набор полей, служащих одному назначению в предметной области.

Фамилия, Имя, Отчество в одной таблице - это тоже массив, и нарушение 1НФ ?

Нет, это разные атрибуты, у них назначение разное.

Одно -- фамилия, другое -- имя, третье -- отчество.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436883
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинMasterZiv,

Боюсь, Вы не понимаете, что такое нормализация и какие задачи она решает.

MasterZivЗадай вопрос " получить список свойств квартиры, которые она имеет" и ты все поймешь.
"Получить свойства квартиры в виде списка " - это, грубо говоря, выходная форма. Проектировать БД исходя из выходных форм - плохая практика. Завтра Вас попросят "выдайте нам свойства квартиры одной строкой" - Вы будете переделывать схему данных?


Это запрос, который надо написать. Какая выходная форма ?
Кортежи надо получить, где было бы (Квартира, свойство)
Все свойства, что есть.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436947
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivЭто запрос, который надо написать. Какая выходная форма ?
Кортежи надо получить, где было бы (Квартира, свойство)
Все свойства, что есть.
Еще раз - это неправильная логика, аргументировать схему данных "а вот такой [взятый с потолка] запрос писать проще!" (и уж совершенно точно эта логика не имеет отношения к нормализации, на которую Вы напирали).
Если потребуется написать запрос (квартира, свойство1, свойство2,...свойство15) - Вы будете переделывать схему данных?
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38436972
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> победил второй вариант. Посмотрим, как он покажет себя в действии.

Обычно сначала тестируют, а потом объявляют о победе.

Видите ли, безобразно кривы оба предложенных вами варианта. Особенность в том, что задача и не предполагает не кривых решений. На вашем месте я бы остановился на первом варианте: просто, дёшево, сердито. При необходимости добавить раз в полгода пару полей - не проблема. Только замените в таблице 1/NULL на true/false.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38437311
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivНет, это разные атрибуты, у них назначение разное.

Одно -- фамилия, другое -- имя, третье -- отчество.

Глубина открытия потрясает.

Мне кажется, что между холодильником и стиралкой все же больше разницы. По крайней мере, они не взаимозаменяемы. А ФИО - запросто: в садике всех зовут по именам, в армии - по фамилиям, на пенсии - по отчествам. Чем не "набор полей, служащих одному назначению в предметной области" ?

Просто формальная кривость первого варианта вовсе не в нарушении 1НФ, а в эмпирическом правиле "избегайте индексированных атрибутов". Я не поленился перелистать Дейта, но в формальном виде этого правила не нашел, помню только у обкуренного Джо Селко. Может, кто-то укажет на формальное определение недостатка первого варианта?
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38437897
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cane Cat Fisher,

Я уже указывал, формально это нарушение 1НФ.
...
Рейтинг: 0 / 0
Подскажите на конктретном примере
    #38438986
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cane Cat FisherNekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии.

Добро пожаловать в мир EAV. Для примера, простейший запрос: "Выбрать квартиры, где есть холодильник и стиралка, но нет ни мебели, ни микроволновки". Составьте для первого и второго варианта, сравните.
А Вы, в свою очередь, составьте этот запрос для совершенно правильного Вашего варианта из
15013211
который Вы ошибочно раскритиковали - 1НФ в нем не нарушается никак. И даже после того, как добавят материальный учет, так сказать (конечно, клиентов будет интересовать объем холодильника), то это (тогда - уже вычисляемое) поле вполне может использоваться.
Второй вариант не имеет вообще никакого отношения к БД.
...
Рейтинг: 0 / 0
25 сообщений из 66, страница 1 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите на конктретном примере
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]