Динамическая структура базы данных

Question

Я хотел бы получить предложение по базе данных / программированию по конкретному вопросу.

У меня есть 5 разных людей (которые живут в разных частях света), которые предоставляют мне данные. Эти данные предоставляются мне разными способами в соответствии со стандартной структурой. Однако это не всегда согласовано, у данных могут быть дополнительные вещи, которых нет в стандарте, поэтому я бы хотел, чтобы структура была как можно более динамичной, чтобы соответствовать тому, что человек хочет использовать.

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

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

Мои вопросы:

1. Как сохранить динамическую структуру, не пересматривая стандартную компоновку для размещения новых полей данных или другой структуры?
2. Как заставить их загружать данные пошагово? Например, они могут загружать XML-версию своих данных, мой код загрузки должен выяснить, что уже существует.
3. Мой последний и самый важный вопрос. Есть ли лучшие способы сделать это, вместо того, чтобы загружать инфраструктуру?

Answer 1

Как сохранить динамическую структуру, не пересматривая мою стандартную компоновку для размещения новых полей данных или другой структуры?

По сути, вы сводите обычное представление базы данных о столбцахи строки.

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

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

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

Поле данных содержит все возможные типы данных.Это будет VARCHAR (MAX) в большинстве баз данных.Преобразование дат и чисел в строки зависит от процесса загрузки.

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

Как мне заставить их загружать данные пошагово?Например, они могут загружать XML-версию своих данных, мой код загрузки должен выяснить, что уже существует.

Короткий ответ: вы не можете.

Ваша загрузкаПроцесс должен идентифицировать дубликаты данных, а не сохранять их в базе данных.

Мой последний и самый важный вопрос.Есть ли лучшие способы сделать это, вместо того, чтобы загружать инфраструктуру?

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

Answer 2

Это очень общий вопрос, но я думаю, что у меня есть общий ответ. То, что я думаю, решает вашу проблему - это создать новое реляционное исчисление, в котором свойства, прикрепленные к основной записи, не определены заранее. Вот пример с приложением телефонной книги.

Общий метод с использованием нереляционной таблицы:

• Таблица PERSON имеет столбцы Name, Домашний телефон, офисный телефон.

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

Вместо этого вы делаете:

• Таблица Person имеет столбцы Person_ID, Имя.
• Настольные телефоны имеют столбцы Person_ID, Phone_Type, PhoneNumber.

Между Лицом и Телефоном существует отношение один-ко-многим, и их может быть любое количество от нуля до миллиарда. Таблицы объединяются Person_ID. Вы должны иметь бизнес-логику и логику представления, которая перечисляет столбец Phone_Type (или просто должна быть свободной формы, что не так полезно, но проще).

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

Answer 3

Как уже говорили другие, таблицы EAV могут обрабатывать динамическую структуру.(помните о проблемах производительности больших таблиц)

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

Вы можете заставить клиента соответствовать вашей модели?Это позволяет вам заранее знать поля и использовать бизнес-логику для этих полей.Он также позволяет вам создавать значимые отчеты, а не просто сводить дампы данных.