Блог

У меня есть электронная таблица Excel, которую я собираюсь превратить в базу данных для сбора данных и создания интерактивного приложения. Имеется около 20 столбцов и 80 000 записей. Практически во всех записях около половины данных их столбцов имеют значение null, но данные, содержащиеся в столбце, являются случайными для каждой записи.

Варианты могут заключаться в:

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

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

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

Подумайте о том, чтобы вставить связь между клиентом и продуктом (в основном заказом). Вам пришлось бы:

1. выберите строку, которая описывает остальные данные, но имеет нули или что-то в столбцах product
2. вы должны обновить столбцы продукта
3. вам нужно вставить ОГРОМНУЮ строку в базу данных

Как насчет первого раза? Что вы делаете с начальными значениями null? Вы изменяете свои выборки, чтобы игнорировать их? Что, если вам нужны значения null?

Что, если вы удалите последний продукт? Вы меняете ее на обновление и устанавливаете нули только для нескольких столбцов?

Помимо объединений, работа с нормализованной таблицей тривиальна по своей конструкции. Вы платите за ее тривиальность производительностью, это фактический компромисс.

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

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

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

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

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