Будет ли теоретически работать «разыменование» внешнего ключа в SQL? - PullRequest
Новая
       2

Будет ли теоретически работать «разыменование» внешнего ключа в SQL?

1 голос
/ 14 июня 2011

Предположим, у нас есть 2 таблицы, a и b: 

CREATE TABLE a (id_a INT NOT NULL PRIMARY KEY, id_b INT NOT NULL)
  INDEX fk_id_b (id_b ASC),
    CONSTRAINT fk_id_b FOREIGN KEY (id_b)
    REFERENCES b (id_b);
CREATE TABLE b (id_b INT NOT NULL PRIMARY KEY, b_data INT NOT NULL);

Итак, a имеет следующие столбцы: id_a и id_b, где id_b - внешний ключ для b sid_b.Когда я хочу получить связанные b_data от a, я должен сделать соединение: 

SELECT id_a, b_data FROM a JOIN b ON a.id_b=b.id_b;

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

SELECT id_a, id_b->b_data FROM a;

foreign_key->column будет вести себя как указатель на структуру, база данных автоматически объединит необходимые таблицы.

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

Ответы [ 3 ]

8 голосов
/ 14 июня 2011

Первый

  • Ruby не является SQL, SQL не является Ruby
  • SQL также предшествует почти всем текущим основным или модным языкам

Однакоодна вещь, которую нужно иметь в виду, и самое важное ...

Повторение JOIN - это не то же самое, что повторение запроса.У вас будут разные

  • ГДЕ фильтры
  • ВЫБРАТЬ список
  • Может быть, совокупность

Каждый из них является различным запросом и будетпотребовать разные индексы / планы

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

Использование индексированного представления не может быть решением из-за различных фильтров и т. Д.

Правка из Dems:

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

3 голосов
/ 14 июня 2011

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

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

2 голосов
/ 14 июня 2011

SQL имеет оператор NATURAL JOIN, например Ваш запрос будет: 

SELECT DISTINCT * 
  FROM a NATURAL JOIN b;

Однако похоже, что вы хотите сделать полусоединение , для которого в SQL нет специального оператора: (

Поскольку вас интересует проектирование языка, рассмотрите действительно реляционный язык В учебном пособии D (предназначенном для академических целей) есть оператор полусоединения MATCHING, например. Ваш запрос будет просто: 

a MATCHING b;
...