Вопрос дизайна MySQL - что лучше, длинные таблицы или несколько баз данных?

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

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

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

Я сталкивался с похожими проблемами, когда пользователям нужны данные, извлеченные из нормализованной схемы. Схема НЕ меняется. Однако их требуемый выходной формат требует фиксированного количества иерархических уровней. Таким образом, несмотря на то, что дизайн базы данных учитывает все изменения, которые они хотят внести, выбранное ими представление этих данных не может быть сохранено перед лицом их изменений. Таким образом, невозможно поддерживать выходную схему при изменении данных (даже при изменении схемы). Это не означает, что это недопустимая схема вывода или ввода, но существуют ограничения, за пределами которых нельзя использовать выбранную ими схему. На этом этапе они должны пересмотреть выходной контракт, программа сводки (которая МОЖЕТ предвидеть это и создать новые столбцы) может иметь место для размещения данных в выходной схеме.

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

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

Даже в ситуации ETL с хранилищем данных новый столбец должен быть определен, является ли он фактом или атрибутом измерения, а затем, если это атрибут измерения, какой таблице измерения его лучше всего назначить. Это может быть несколько автоматизировано для фактов (очевидными кандидатами будут скаляры, такие как десятичные/числовые), проверив метаданные на наличие несопоставленных столбцов, изменив таблицу DW (да) и затем загрузив соответствующим образом. Но что касается размеров, я бы с опаской относился к автоматизации чего-то подобного.

Подводя итог, я бы сказал, что изменения схемы в хорошем нормализованном дизайне базы данных наименее вероятны, потому что: 1) дизайн базы данных уже предвосхищает и приспосабливается к большому количеству изменений и гибкости и 2) изменения схемы к такому дизайну базы данных вряд ли можно легко ожидать. И наоборот, изменения схемы в плохо нормализованной структуре базы данных на самом деле легче предвидеть, поскольку недостатки в структуре базы данных более заметны.

Итак, мой вопрос к вам: насколько хорошо спроектирована база данных, с которой вы работаете?

Вы говорите, что знаете, что вам предстоит много программировать...

Я не уверен в этом. Я бы выбрал быстрое и грязное решение, а не «общее» решение, потому что общие решения, такие как модель значений атрибутов объекта, часто имеют плохую производительность. Не выполняйте соединение на стороне клиента (объединение результатов) внутри вашего кода Python, потому что это очень медленно. Используйте SQL для присоединения, он предназначен для этой цели. Пользователи также могут создавать свои собственные отчеты с помощью всевозможных инструментов отчетности, которые генерируют операторы SQL. Вам не нужно делать все в своем приложении, просто начните с решения 80% проблем, а не 100%.

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

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

Мне кажется, что ваша проблема на самом деле не в MySQL или SQLlite. Речь идет об обмене данными и договоре, который должен существовать между поставщиком данных и пользователем тех же данных.

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

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

Я не знаю специфики вашей ситуации, поэтому то, что следует дальше, может быть далеко от цели.

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

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

По крайней мере, ETL собирает все сложные проблемы в одном месте. Как только вы загрузите данные в базу данных, созданную для ваших нужд, а не для нужд ваших поставщиков, преобразование данных в ценную информацию должно быть относительно простым, по крайней мере, на уровне программирования или SQL. Существуют даже инструменты OLAP, которые делают использование данных таким же простым, как видеоигра. На этом уровне есть проблемы, но это не те проблемы, о которых я говорю здесь.

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