Должна ли сущность сопоставляться со своей собственной таблицей базы данных?

Я делаю некоторую работу, используя Azure и Idea Blade DevForce, и мне интересно, какой лучший подход с точки зрения сопоставления сущностей с таблицами базы данных...

Должна ли сущность иметь собственную таблицу в базе данных? Есть ли какая-либо выгода/ущерб производительности для этого?

Скажем, у нас есть сущность «Заказ», сущность «Продукт», сущность «Клиент» и сущность «Адрес»; каковы плюсы и минусы смешивания их в одной таблице по сравнению с разделением их всех? Очевидно, что база данных не была бы в 3-й нормальной форме, если бы мы не разделились, но имеет ли это значение при использовании MEF / DevForce?

В качестве второго (менее надуманного) примера, что, если бы у нас была сущность «Учетная запись» и сущность «Пользователь»; у учетной записи может быть много пользователей, но пользователи могут принадлежать только одной учетной записи... Таким образом, размещение их всех в одной таблице не дублирует никаких пользовательских данных, но я (лично) все еще думаю, что этот подход совершенно неверен. Есть ли причины, по которым это было бы выгодно?


person Siyfion    schedule 14.02.2012    source источник
comment
Вас интересует только производительность или другие вещи, такие как ремонтопригодность и т. Д.   -  person Fen    schedule 14.02.2012
comment
Нет, меня тоже очень интересует ремонтопригодность! Нам нужно иметь возможность вносить изменения в модель, которые не нарушают полностью существующие сохраненные элементы!   -  person Siyfion    schedule 14.02.2012


Ответы (1)


Зависит от того, насколько вам нравится дублировать данные и хотите ли вы, чтобы кто-то воспринимал вас всерьез как разработчика. Сбрасывать все в кучу — это худший антипаттерн, который я могу придумать.

Скажем, например, вы хотите создать 4 заказа для 2 клиентов, каждый из которых содержит 5 продуктов. Одни только данные вашего клиента будут повторяться 10 раз для каждого клиента.

РЕДАКТИРОВАНИЕ: я должен отметить, что мой ответ на этот вопрос — решительное «да». Мне было бы интересно услышать аргументы ЗА альтернативу...

person Tieson T.    schedule 14.02.2012
comment
Честно говоря, это именно то, что я думаю, но я просто хотел убедиться, что это не привело к значительной потере производительности / потери гибкости, поскольку это не то, что в настоящее время хочет делать другой разработчик. - person Siyfion; 14.02.2012
comment
Я добавил второй пример, хотя до сих пор не вижу причин помещать их все в одну таблицу, если только это не снижает производительность. MySQL или Azure будут механизмом хранения в фоновом режиме. - person Siyfion; 14.02.2012
comment
Вы, скорее всего, столкнетесь с проблемами производительности, если у вас есть активное приложение, использующее этот объект сохранения. Я работал с устаревшими таблицами с такой настройкой, и мне было тяжело пытаться определить уникальную запись, не включив множество полей в предикат... но это мой личный опыт. - person Tieson T.; 14.02.2012
comment
Я согласен, но, как вы сказали в своем редактировании, я хотел бы получить консенсус во мнениях и посмотреть, есть ли у кого-нибудь какие-либо аргументы в пользу хранения одной таблицы!? - person Siyfion; 14.02.2012