Как связать таблицу базы данных N с одним мастер-таблицей?

Question

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

Теперь я хочу создать один «MasterTable» с несколькими столбцами.

| MasterTable | 
|id. | title| isbn|  
| 1 | abc | 123 | 


| MasterToBookstores | 
|m_id | tb_id | p_id | 
| 1 | 1 | 2 | 
| 1 | 2 | 1 | 


|  BookStore_Foo   | 
|p_id| title| isbn| date | size|  
| 1 | xyz | 456 | 1998 | 3KB | 
| 2 | abc | 123 | 2003 | 4KB | 

|  BookStore_Bar     | 
|p_id| title| isbn| publisher | Format |  
| 1 | abc | 123 | H&K  | PDF | 
| 2 | mnh | 986 | Amazon | MOBI | 

Мой вопрос: правильно ли хранить данные таким образом? Каковы наилучшие практики в этом и подобных случаях? Могу ли я предоставить конкретную таблицу Bookstore псевдониму с номером, который поможет мне управлять целым набором таблиц?

Есть ли лучший способ сделать такую ​​вещь?

Answer 1

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

UPDATE:

Если вы используете рамки сущности для подключения к БД я предлагаю вам попробовать это:

Создайте ваши объекты модели что-то вроде этого:

то пусть структура сущности создает базу данных (обновить базу данных из модели) для вас. Обратите внимание, что это использует наследование (а не в базе данных).

Дайте мне знать, если у вас есть вопросы.

Answer 2

Предлагайте модель данных:
1. Иметь основную базу данных, которая сохраняет основные данные
2. Таблицы размеров в основной базе данных, transtional репликации в распределенной базе данных книжного магазина
3. Вы можете использовать обновляемый scriscriber или репликация слияния также является хорошим выбором.
4. Каждая распределенная база данных книжных магазинов все еще работает независимо, однако основные данные либо сбрасываются путем репликации слиянием, либо обновляемого абонента.
5. Если вы хотите убедиться, что целостность основных данных вы можете использовать только для чтения, и использовать трансационную репликацию для распространения основных данных в распределенной базе данных, но в этом дизайне вам необходимо иметь процедуры хранения в основной базе данных для регистрации ваши данные измерений. Удостоверьтесь, что проблема с двойным переходом отсутствует.

Answer 3

Я думаю, вы вводите в заблуждение понятия «магазин» и «книга».

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

Символ: обозначает уделом . КНИГА является «базовым классом», а BOOK1/BOOK2/BOOK3 являются различными «подклассами» . Это общая стратегия, когда объекты имеют набор атрибутов или отношения .Для более полного объяснения этой концепции, пожалуйста, найдите «Подтипные отношения» в ERwin Methods Guide.

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

• Interpreting ER diagram
• Parent and Child tables - ensuring children are complete
• Supertype-subtype database design

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

---

Aka. категория, подклассов, подтипы, обобщение иерархии и т.д.

Т.е. типы книг, в зависимости от того, какие атрибуты они требуют.

В этом случае книги всех типов в многие-ко-многим с магазинами.

Answer 4

Я хотел бы предложить вам две таблицы:

Bookstores:

idnamesomeMoreColumns

книги:

idbookStore_idtitleisbndatepublisherformatsizesomeMoreColumns

Легко видеть отношения здесь: а bookStore имеет много books.

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

Почему я предпочитаю этот путь:

1) Для всех данных из таблиц BookStore, только несколько колонн будет никогда имеют значение по таблице books (как, например, size и format, если у вас нет версия электронной книги). Другие столбцы могут быть заполнены когда-нибудь (вы можете установить date в свои электронные книги, но у вас нет этого столбца в таблице BookStore_Bar, который, как представляется, относится к электронным книгам). Таким образом, вы можете получить гораздо более подробную информацию из всех своих книг, если когда-нибудь захотите ее обновить.

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

• Первое: запустить вручную запрос для каждого из 12 таблиц и поэтому объединить данные;

• Во-вторых: написать запрос с 12 соединениями или установить 12 таблиц в вашем предложении FROM, чтобы запросить все ваши данные;

• Third: быть зависимым от какого-либо скрипта, хранимой процедуры или программного обеспечения, чтобы сделать для вас первый или второй способ, который я только что сказал;

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

3) Что касается MySQL (потому что я знаю гораздо больше MySQL), вы можете использовать partitions на своей таблице books. Это высокий уровень управления данными, в котором вы можете распространять данные из своей таблицы на несколько файлов на вашем диске, а не только на один, как обычно выделяется таблица. Это очень полезно при обработке большого количества данных в одной таблице и ускоряет запросы на основе вашего плана распространения данных. Давайте посмотрим на пример:

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

Допустим, вы хотите запросить таблицу books на bookStore_id в (1, 4, 9). Если ваш запрос действительно нужен только для этих трех разделов, чтобы дать вам желаемый результат, другие не будут запрашиваться, и они будут такими же быстрыми, как вы запрашивали каждую отдельную таблицу.

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

Побочные эффекты:

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

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

Надеюсь, это поможет!