Должен ли я объединить две одинаковые таблицы в одну?

Question

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

Для быстрого объяснения, с моим проектом, каждый год компании представляют мне список поставщиков, которым они продают, а также покупают вещи. Поскольку это делается на ежегодной основе, у меня есть таблица с именем sales и одна с именем purchases.

Таким образом, в таблице sales у меня были бы такие поля, как: BusinessID, year, PurchaserID и т. Д. И полная противоположность была бы в таблице purchases, за исключением того, что SellerID.

Таким образом, в основном обе таблицы имеют одинаковое поле, за исключением PurchaserID / SellerID. Я унаследовал эту систему, поэтому я не проектировал БД таким образом. Я обсуждаю объединение двух таблиц в одну таблицу под названием suppliers и просто добавляю поле type, чтобы различать, продают ли они или покупают по.

Это звучит как хорошая идея? Я что-то упускаю из-за того, почему это не будет хорошей идеей?

Answer 1

Делай то, что работает для тебя.

Ответ из учебника: нормализовать . Если бы вы нормализовались, у вас, вероятно, было бы 2 таблицы, одна с вашими покупателями и продавцами как компаниями . И таблица транзакций, показывающая, кто что купил у кого.

Answer 2

Если это не сломано, не исправляйте это. Оставьте их отдельно.

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

Но звучит так, что к этим двум группам относятся очень по-разному с точки зрения бизнес-правил, поэтому, вероятно, на этом этапе внесение изменений в приложение не стоит (Каждый запрос должен иметь "WHERE Type = 1" или что-то подобное).

Если бы вы спросили об этом на этапе разработки БД, мой ответ мог бы быть другим.

Answer 3

Не один стол. Это разные сущности, которые имеют похожую структуру. Ничего нельзя получить, консолидируя их. (Ничего не потеряно, кроме ясности; но это важно ИМХО).

«Нормализация» не включает поиск таблиц с похожими схемами и их объединение.

Answer 4

Определенно одна таблица. И я бы не назвал это поставщиком, поскольку это не отражает значение таблицы. Что-то вроде busibess_partner или что-то лучше этого может быть более подходящим. Вместо purchase_id и seller_id укажите более общий тип, например business_partner_id, и добавьте поле для различения.

Answer 5

Нормализация скажет "да".

На сколько приложений влияет это изменение? Это повлияет на решение.

Answer 6

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

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

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

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

Answer 7

Поскольку ни один из экспертов , готовых ответить на ваш вопрос, не может ответить на ваш вопрос, простой ответ: query1 UNION query2

EX. SELECT * FROM table1 UNION SELECT * FROM table2 при условии, что table1 и table2 имеют одинаковую структуру / заголовки заголовков

Answer 8

С логической точки зрения, между отчетными транзакциями нет никакой разницы, это просто разница в том, кто сообщает об этом вам. Это должна быть одна таблица с идентификатором SellerID, BuyerID и (если вам это нужно) ReporterID (s) (и, возможно, дополнительной информацией о транзакции).

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

Answer 9

С совершенно другой точки зрения. Я склонен рассматривать логику над технологиями. Для меня решение заключается не в том, похожи ли данные по форме или полям, а в том, имеет ли смысл их смешивать. То же самое можно сказать и о том, что если технический ответ будет нормализовать , мой ответ будет таким: имеет ли смысл для вас (бизнес-логика) иметь оба вместе?

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

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

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

Answer 10

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

Пример: кто продавал компьютеры нам и кому мы их продавали.