Какая логика лежит в основе только визуального построителя запросов SELECT? - PullRequest
2 голосов
/ 12 июля 2011

Технологии: VS.net 2008, C #, Winforms, SQL Server 2008

Итак, я как-то облажался на работе и, видимо, только что пообещал предоставить клиенту визуальный построитель запросов всего за 1 неделюоставил в проекте.(Я новичок в работе с клиентами)

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

Достаточно просто получить таблицы и списки столбцов БД, а также способы создания частей "ГДЕ", "И" и "ИЛИ", но яне знаю, как мне следует думать о написании объединений.

Я должен его разработать, потому что для использования внешнего приложения или .dll потребуется получение одобрения, которое может занять более года (не вариант)

Существует ли жесткое и быстрое правило, которое гласит: «При написании оператора select вы используете таблицу с наибольшим количеством результатов в качестве таблицы« FROM »и т. Д.)

Я заметил, что MS Access в основном это делаетОставил Joins, но я не понимаю, почему.

РЕДАКТИРОВАТЬ: мне больше не нужно создавать его к концу этой недели, так как проект откладывается из-за архитектурных проблем, однако ябудет снова задавать этот вопрос в надежде получить ответ на «логику» за заявлениями о присоединении

Ответы [ 2 ]

4 голосов
/ 12 июля 2011

Вот класс CodeProject, который может быть вам полезен

http://www.codeproject.com/KB/database/SelectQueryBuilder.aspx

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

http://www.blackbeltcoder.com/Articles/strings/a-sql-querybuilder-class

Удачи, и помните ... под обещание / сверх доставить.Не наоборот :)

(сердитесь, мы все это сделали - даже те, кто этого не признает)

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

Настоящая «логика» объединений SQL входит в реляционную алгебру (я думаю, что Википедия имеет хороший обзор высокого уровня - http://en.wikipedia.org/wiki/Relational_algebra). Это большая тема, ей посвящены целые классы / книги.

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

Если вы пишете свой собственный визуальный построитель запросов, вам действительно нужен способ дляПользователь может указать, какой тип объединения он хочет, и создать из него действительный SQL.Большинство инструментов, которые я видел, используют левые внешние соединения (как вы упоминали в Access), потому что клиенты / клиенты / пользователи неизбежно будут иметь неверные или отсутствующие данные.Когда вы выполняете внутреннее соединение, они говорят: «Ваш инструмент не работает, у меня должно быть 250 строк, а у меня только 232».Если вы выполняете внешнее соединение, они говорят: «У меня 250 строк, но в некоторых из них отсутствуют данные ... Я бы лучше это исправил».Левое объединение кажется более естественным для большинства людей (по крайней мере, я полагаю, в тех местах, где люди читают слева направо).

Если вы хотите, чтобы ваш построитель запросов поддерживал все, что возможно в SQL - вы 'У нас есть огромный, огромный, огромный проект .... и, как уже говорили другие - вы облажались.Но у приложения, над которым я работал , было , и людям это не понравилось.Они хотели очень простой, ограниченный способ построения запросов.Это может быть довольно легко.Я думаю, у вас есть отличный шанс собрать что-то в этом духе.«Простой» инструмент построения запросов, который я собрал, использовал восемь предопределенных запросов и позволял пользователю предоставлять критерии во время выполнения.Они не могли добавлять таблицы, они не могли изменять типы соединений, они не могли создавать объединения, агрегаты или что-либо еще.Но они используют это больше, чем полнофункциональный «продвинутый» коммерческий инструмент, который мы приобрели.

Надеюсь, это немного поможет.Удачи!

...