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

Question

Я работаю с существующей унаследованной клиентской базой данных, которую мы конвертируем в MySQL для онлайн-использования.

это фактически одна гигантская таблица, и никаких связей не существует.

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

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

так что - AFAICT - здесь нет реальной«использовать» для таблиц отношений, за исключением, возможно, семантики или прозрачности.набор данных не очень большой, но и не маленький (от 50 000 до 100 000 записей), поэтому мне интересно, может ли быть эффективнее просто сохранить структуру единой таблицы и пропустить объединения в целом.

есть ли причина использовать отдельные таблицы в такой ситуации?

tyia

Answer 1

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

• Существует ли много запросов, в которых используется оператор *, извлекающий все столбцы из базы данных, или запросы достаточно зрелые, чтобы не включать те столбцы, которые не требуются. В первом случае вы можете переместить их в отдельную таблицу из соображений производительности
• Будет ли когда-нибудь в будущем требование, когда для записи потребуется несколько «контактных» записей. Вы можете сэкономить несколько головных болей, выполнив конвертацию сейчас или позже

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

Answer 2

Абсолютно, даже если только для предотвращения технического долга .

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

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

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

Answer 3

Нет смысла выделять имя, фамилию, название, улицу, город, штат, почтовый индекс.Единственная веская причина для этого - добавить значение к каждому из этих полей, например, вы можете определить «город» в терминах «штат», потому что они связаны, но тогда вам понадобится столбец идентификатора для устранения неоднозначности «Спрингфилд»,Неправильная форма Springfield, Mass и запросы будут усложняться, а производительность будет незначительно хуже.Поэтому в данном случае сохранение всего этого в одной таблице в «ненормализованной» форме кажется мне разумным.

Answer 4

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