Трябва ли даден обект да се преобразува в собствената си таблица на база данни?

Върша малко работа, използвайки Azure и Idea Blade DevForce и се чудя кой е най-добрият подход по отношение на картографиране на обекти към таблици на база данни...

Трябва ли даден обект да има собствена таблица в базата данни? Има ли някаква полза / вреда за това?

Да кажем, че имаме обект „Поръчка“, обект „Продукт“, обект „Клиент“ и обект „Адрес“; какви са предимствата и недостатъците на смесването на тези в една таблица срещу отделянето им всички? Очевидно db нямаше да бъде в 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