SQL Design Вопрос относительно схемы, и если пара имя-значение является лучшим решением - PullRequest
1 голос
/ 01 июня 2010

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

Приложение анализирует файл на основе пользовательского ввода и вводит эти данные в базу данных. Количество полей, которые могут быть проанализированы, находится в диапазоне от 1 до 42 в текущий момент.

Текущий дизайн базы данных полностью плоский с 42 столбцами; некоторые имеют повторяющиеся столбцы, такие как адрес1, адрес2, адрес3 и т. д.

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

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

Третий вариант - у меня есть таблица, в которой определены поля, и таблица для каждой записи. Итак, я подумал о том, чтобы создать таблицу, в которой будет храниться значение, а затем ссылки на эти две таблицы. Проблема в том, что я могу изобразить размер этой таблицы, увеличивающейся в зависимости от размера ввода. Если кто-то дает мне файл с 300 000 записей, то 300 000 x 40 = 12 миллионов, поэтому у меня есть некоторые оговорки. Тем не менее, я думаю, что если я доберусь до этой точки, я буду счастлив, что ее используют. Эта опция также позволяет более настраиваемое отображение информации, хотя немного больше работы, но немного доработки, даже если вы добавите больше полей.

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

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

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

Спасибо за ваше время.

Ответы [ 2 ]

0 голосов
/ 01 июня 2010

Относительно этой части вашего вопроса

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

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

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

0 голосов
/ 01 июня 2010

Всегда хорошо, чтобы проверить здравомыслие.

Самородок в вашем утверждении таков:

они хотят добавить больше полей для анализа

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

Возможно, сохраните те атрибуты, которые являются единичными для сущности ... т.е. Для тех, которые повторяются, то есть "Address1" через "AddressX" или "Phone1" через "PhoneX".

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...