Объединение таблиц на основе внешних ключей


У меня есть таблица, в которой много полей, являющихся внешними ключами, ссылающимися на связанную таблицу. Я пишу скрипт на PHP, который будет выполнять запросы к БД. Когда я запрашиваю эту таблицу для ее данных, мне нужно знать значения, связанные с этими ключами, а не ключ.

Как большинство людей справляются с этим?

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

Вопрос 1: я думаю, что мог бы написать 1 запрос с кучей соединений. Может, так будет лучше?

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

Вопрос 2: Как насчет идеи запрашивая таблицу и определяя, каковы ограничения, а затем сопоставляя их, используя любой процесс, который я решаю из вопроса 1. Мне нравится эта идея, но я никогда не видел, чтобы она использовалась в коде. Заставляет меня думать, что это не очень хорошая идея по какой-то причине. Я бы использовал что-то вроде SHOW CREATE TABLE tbl_name; чтобы найти, какие ограничения/отношения существуют для этой таблицы.

Спасибо за любые предложения или советы.

3   3   2011-03-02 00:12:51

3 ответа:

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

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

На каком-то уровне система должна выполнять запросы с использованием соединений, независимо от того, написаны ли эти запросы явно прикладным программистом или сгенерированы автоматически уровнем доступа к данным . Вариант 1 определенно лучше, чем наивный вариант. Что касается некоторых других вариантов создания запросов (далеко не исчерпывающий список):

  • Вы можете абстрагировать все операции базы данных, так же как PDO абстрагирует операции подключения и запроса (т. е. подготовку и выполнение запросов). Воспользуйся это позволяет получить метаданные таблицы, включая внешние ключи, которые затем могут использоваться для автоматического построения запросов.
  • Вы можете написать спецификации объектов в каком-либо другом формате (например, XML) и класс, который будет использовать его для создания классов PHP и таблиц базы данных. Вы найдете это больше в корпоративных приложениях, чем в небольших проектах. Этот вариант имеет больше накладных расходов, чем другие, и поэтому не подходит, если у вас есть только несколько классов для моделирования. Вхождения этого варианта также могут быть следствие Закона Конвея, который я впервые услышал как вариант Ричарда Фэрли: "структура системы отражает структуру организации, которая ее построила."
  • можно использовать подход, подобный подходу LINQ. В PHP это означало бы написание множества функций или методов, которые программист приложения может связать вместе, чтобы создать запрос. Прикладные программисты в конечном счете отвечают за объединение таблиц, хотя они никогда не пишут JOIN самих себя.

Вместо того, чтобы думать о том, как создавать запросы, лучший подход к решению проблемы-это думать о том, как взаимодействовать с БД и приложением. Это приводит к паттернам , таким как Data Mapper и Active Record, которые попадают в категорию объектно-реляционного отображения (ОРМ ). Обратите внимание, что некоторые паттерны (такие как AR), другие методы ORM и даже сам ORM имеют свои собственные проблемы. Любой из вышеперечисленных запросов параметры создания могут использоваться при реализации шаблона доступа к данным.

Проблема с использованием SHOW CREATE TABLE заключается в том, что он не работает с большинством (всеми?) другими РСУБД. Если вы хотите женить свое приложение на MySQL, идите вперед,но решение может преследовать вас.

С какими типами записей вы работаете, как в основной таблице данных, так и в таблицах подстановки?

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

MySQL включает поддержку каталога INFORMATION_SCHEMA ANSI.РЕЛЯЦИОННОЕ ОГРАНИЧЕНИЕ. Вы можете использовать это для сбора информации о существующих связях FK.

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