Как обрабатывать дизайн таблицы с переменными столбцами

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

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

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

Но каждый год вас попросят записать дополнительную информацию обо всех домах - и КАКАЯ информация будет меняться каждый год. Так, например, в первый год вас просят записать фамилию владельца и квадратные метры. На второй год вас просят сохранить фамилию, но выбросить квадратные метры и вместо этого начать собирать имена владельцев.

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

Таким образом, один табличный подход состоит в том, чтобы попытаться добавить пользовательскую информацию в виде столбцов в домашних таблицах, чтобы была только одна таблица.

Но у меня есть ситуация, когда кто-то выложил таблицы для этого как:

Столбцы "Таблица дома": ID, Адр, Город, Штат, Zip - по одному ряду на дом

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, Имя, Значение - с таблицей, похожей на:

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») и вставьте эти пользовательские значения прямо в ряды домов.

ИЛИ

Б) Храните пользовательскую информацию в домашней таблице, но каждый год, когда меняются требования, перестраивайте домашнюю таблицу только с количеством столбцов, необходимых для пользовательской информации, с мыслью, что требования могут сойти с ума, и вы никогда не узнаете, сколько максимум дополнительные поля могут быть запрошены?

Спасибо, надеюсь, это имеет смысл!

У вас есть 4 варианта:

NoSQL - определение. Каждая запись хранится в виде набора пар ключ / значение. Это очень гибкий и быстрый. Не все авторы отчетов поддерживают этот стиль хранения. Есть много примеров реализации баз данных NoSQL. То, что сейчас кажется самым популярным, это MongoDB.

EAV - определение Здесь вы поворачиваете всю таблицу или часть (в другой таблице) на бок. Это хороший выбор, если у вас уже есть собственная реляционная база данных, от которой вы не сможете легко отойти. Приведенный вами пример пользовательской информационной таблицы является хорошим примером таблицы EAV.

Стандартные таблицы со столбцами XML. Представьте, что NoSQL соответствует реляционным таблицам. Данные, хранящиеся в столбце XML, могут быть любого формата, который поддерживает XML, включая несколько коррелированных субданных. Если вы знаете, что столбцы будут «обычными» столбцами, они могут быть построены как соответствующий тип столбца для хранения данных (Фамилия, Адрес, Город, Штат и т. Д.).

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

Из всех этих решений я считаю, что подход NoSQL или EAV окажется наиболее успешным с наименьшим объемом рефакторинга кода и схемы.

У вас будет ситуация, когда вы будете собирать данные один год, а не следующий, а потом собирать их снова. Попытки обновить более старые данные правильной информацией проблематичны и дороги. Хранение - ни то, ни другое.

Чтобы ответить на ваш вопрос по этим 2 вариантам, ни один из них не кажется мне правильным. А) заблокирует вас и Б) много работы. Текущая схема, которую вы описываете, не так уж плоха (за исключением того, что имя информации («имя», «квадратный фут» и т. Д.) В виде строки вместо идентификатора, на который ссылается таблица поиска.

Тем не менее, это кажется мне хорошим кандидатом на базу данных 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";

Можете ли вы перечислить все сценарии, для которых вы хотели бы хранить эти данные?

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

по одной таблице для каждого сценария, таким образом, по крайней мере, вы будете содержать таблицы в чистоте и сможете избежать хранения адреса улицы в столбце «фамилия» ...

взгляните на этот вопрос о дизайне: /programming/554522/something-like-inheritance-in-database-design