Як поводитися з дизайном столу зі змінними стовпцями

У мене є сценарій розробки таблиць, і я, як тип, який не є DBA, хотів би думати про те, який є більш масштабним.

Скажімо, вам пропонується записати інформацію про будинки для метрополітену, починаючи з невеликого мікрорайону (200 будинків), але з часом зростаючи до 5000000+ будинків.

Вам потрібно зберігати базову інформацію: ID # (унікальний лот #, який ми можемо використовувати як унікальний індекс), Addr, City, State, Zip. Тонка, проста таблиця впорається з цим.

Але щороку вам пропонують записувати додаткову інформацію про всі будинки - і ЩО інформація буде змінюватися щороку. Так, наприклад, перший рік вас просять записати прізвище власників і квадратні кадри. На другий рік вас просять зберегти прізвище, але скиньте квадратні кадри і замість цього почніть збирати імена власників.

Нарешті - щороку кількість зайвих стовпців змінюватиметься. Можна почати з 2 додаткових стовпців, потім перейти до 6 наступного року, а потім повернутися до 2.

Отже, один підхід таблиці полягає в тому, щоб спробувати додати користувацьку інформацію у вигляді стовпців у домашніх таблицях, щоб була лише одна таблиця.

Але в мене є ситуація, коли хтось викладав таблиці для цього як:

Стовпці "Домашня таблиця": ідентифікатор, адреса, місто, штат, поштовий індекс - з одним рядком на будинок

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

Стовпці "Спеціальна таблиця інформації": ідентифікатор, ім'я, значення - таблиця виглядає так:

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage 

Таким чином, існує кілька рядків для кожного окремого запису будинку. Щороку, коли потрібна необов'язкова інформація змінюється, ця таблиця буквально переробляється, тому наступного року вона може виглядати так:

1    Last Name    Smith

2    Last Name    Harrison

3    Last Name    Markey

1    First Name   John

2    First Name   Harry

3    First Name   Jim

Врешті-решт, ви наберете 100 000 домашніх рядів І на рік з’являється 10 додаткових відомостей; друга таблиця наразі складає 1 000 000 рядків інформації, багато з яких мають зайву (описову) інформацію. Загальні вимоги до бази даних полягають у тому, що людям потрібно буде отримувати інформацію про домашні ряди + пов’язані значення спеціальних полів тисячі разів на день.

Тож моє запитання: чи погана (або жахлива) практика замість того, щоб:

A) Розкладіть таблицю будинку з відгадкою на макс. # Користувацьких стовпців (називається можливо "від 1" до "10") та вставляйте ці власні значення прямо в рядки будинку

АБО

B) Зберігайте нестандартну інформацію в домашній таблиці, але щороку, коли вимоги змінюються, перебудовуйте таблицю будинку лише з # стовпцями, необхідними для користувацької інформації, з думкою, що вимоги можуть збитися, і ви ніколи не знаєте, скільки максимальних необов'язкові поля можуть бути запрошені?

Дякую, сподіваюся, це має сенс!

У вас є майже 4 варіанти:

NoSQL - визначення Кожен запис зберігається як набір пар Ключ / Значення. Це дуже гнучко і швидко. Далеко не всі автори звітів підтримують цей стиль зберігання. Існує багато прикладів реалізації баз даних NoSQL. Той, який, здається, зараз найпопулярніший - це MongoDB.

EAV - визначення Тут ви повертаєте або всю таблицю, або частину (в іншій таблиці) на її сторону. Це хороший вибір, якщо у вас вже є реляційна база даних, до якої не можна легко відійти. Приклад спеціальної інформаційної таблиці, який ви подали, є хорошим прикладом таблиці EAV.

Стандартні таблиці з стовпцями XML - Подумайте про це, як NoSQL відповідає реляційним таблицям. Дані, що зберігаються у стовпці XML, можуть мати будь-який формат, який підтримує XML, включаючи множинні корельовані піддані. Для стовпців, для яких відомо, що вони будуть "звичайними" стовпцями, вони можуть бути побудовані як відповідний тип стовпця для зберігання даних (LastName, Адреса, Місто, Штат тощо).

Стандартні таблиці з великою кількістю зайвих стовпців - у вас є реляційна база даних, ви не можете використовувати ні XML, ні EAV, і NoSQL - це не варіант. Додайте багато зайвих стовпців кожного типу. Я б здогадався, 30 чи більше варчарів, 30 чи більше цілих чисел, 15 чи більше числових знаків. І як тільки ви використовуєте стовпець для значення, не використовуйте його повторно . І не видаляйте стовпчик також.

З усіх цих рішень, моя власна думка полягає в тому, що ви виявите, що підхід NoSQL або EAV є найбільш успішним з найменшою кількістю рефакторингу коду та вашої схеми.

У вас виникне ситуація, коли ви збираєте дані один рік, а не наступний, а потім знову збираєте їх. Намагатися оновлювати старі дані правильною інформацією проблематично і дорого. Зберігання - це не те.

Щоб відповісти на ваше запитання щодо цих двох варіантів, мені це не здається правильним. А) заблокує тебе і Б) - це велика робота. Поточна схема, яку ви описуєте, не надто погана (за винятком того, що інформаційна назва ("ім'я", "квадратний фут" тощо) є рядком замість ідентифікатора, посилається на таблицю пошуку.

Однак мені це здається хорошим кандидатом у базу даних NoSQL ( http://en.wikipedia.org/wiki/NoSQL ). Хоча я ніколи не працював з такою базою даних, те, що ви описуєте, є типовим сценарієм, який вирішує це.

Якщо паралельна кількість спеціальних стовпців обмежена, а обмеження відомі (наприклад, не більше 10-20 спеціальних стовпців для рядків, не більше x стовпців для цілих чисел тощо),
ви можете використовувати базову таблицю з додатковими полями на тип даних і замість цього щороку відбудовуючи таблицю, створюйте подання для цього року, включаючи лише відповідні спеціальні стовпці та перейменуючи загальні поля, щоб відобразити вміст цього року.

House Table:
ID, Addr, City, State, Zip, custom_string1,cs_2,cs_3,custom_integer_1,ci_2,ci_3 ...

create view house_2014 as 
select ID, Addr, City, State, Zip,
custom_string1 as last_name,cs_2 as first_name ...

Проблема такого підходу полягає в тому, що у вас немає історії, але ви могли легко робити копію щороку, перш ніж змінювати вимоги стовпців.

create table house_2014_archive as select * from house_2014;
drop house_2014;
create view house_2015 as "select column list for new year";

Чи можете ви перерахувати всі сценарії, для яких ви хочете зберегти ці дані?

якщо є кінцева кількість комбінацій стовпців, які можуть бути застосовані до таблиці, то спробуйте моделювати "базову таблицю" із загальними стовпцями, які gpopo застосовувати до всіх сценаріїв, а потім створити більше таблиць (для реалізації певного спадкування; це відоме як підтип / суперпертип у проектуванні ERD та бази даних.)

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

Погляньте на це питання дизайну: /programming/554522/something-like-inheritance-in-database-design