Чи створюють SQL розробники SQL-запити за допомогою конструкторів запитів SQL?


13

Мені було просто цікаво, чи SQL Devs пише свій код від руки або вони використовують дизайнер візуальних запитів для створення запитів? У більшості випадків дизайнер запитів може створити більшість нескладних запитів, ні? (Я розробник WinForms зараз починаю працювати з SQL Server)


4
Я використовую конструктор візуальних запитів, його називають emacs. Іноді я зроблю це "від руки" in vi.
дієтабудда

Відповіді:


29

Я не можу говорити ні про кого іншого, але зазвичай просто набираю SQL у "від руки", як ви це сказали . Більшість дизайнерів візуальних запитів, здається, збільшують складність, а не зменшують її. Слід додати, що я також не пишу SQL ніде поблизу штатного.


1
Я погоджуюсь, хоча я зазвичай просто реміксую SQL запити, які я знаходжу в Мережі. Дизайнери візуальних запитів начебто припускають, що ви знаєте мову запитів.
Dan Rosenstark

4
+1 для "... здається (мені) збільшити складність, а не зменшити її"
ozz

тут же (хоча я використовую в основному Oracle, а не MS SQL). Створений SQL має тенденцію бути повільним, надмірно складним.
jwenting

10

Я впевнений, що це залежить, але я ніколи не використовую візуальних дизайнерів. Коли ви добре відчуваєте SQL і думаєте в SQL, його написання стає другим характером. Мені було б набагато більше страждати, використовуючи будь-якого візуального дизайнера, ніж просто писати необроблений SQL.


5

Я б сказав, що переважна більшість досить досвідчених розробників пише це вручну. Я впевнений, що деякі нові або нові міста можуть використовувати візуальні дизайнери, але коли ви отримаєте деякі основи вивчення SQL вручну, це набагато швидше.


5

Я вважаю, що дизайнери запитів, як правило, повільні та громіздкі і не завжди можуть обробляти складні запити. Багато разів мені доводилося копіювати / вставляти запит до якогось інструменту (зазвичай це Access / Excel), який потім витрачає кілька хвилин на обробку запиту, перш ніж заявити, що він просто не може його обробити, і він надсилає мене до редагування тексту. режим.


3

Кожен раз, коли я хочу вивчити новий інструмент / мову. Я змушую себе вводити це вручну. HTML, XAML, SQL. Таким чином я знаю, як виправити те, про що говорить дизайнер. Після того, як мені добре писати рукою, я змушую себе якнайбільше вивчити дизайнера.

Будучи хорошими з обома, давайте вам найкраще з обох світів ... Є щось, що буде ефективніше робити з дизайнером та іншими, які ефективніше в коді. Навчити себе обом дозволяє уникнути недоліків будь-якого.


3

Я не використовую генерацію запитів для створення моїх запитів, я будую їх вручну спочатку (в основному тому, що нічого, окрім тривіального мотива запитів, важко написати в query designer.

Але для великих систем цього недостатньо. Більшість систем БД з великою вагою надають інструмент аналізу запитів, який займе запит і покаже вам Query Execution Plan. Потім ви можете використовувати це (за допомогою інших інструментів), щоб спробувати оптимізувати Запит.

Ви не тільки допоможете з самим запитом, але і дадуть вам вказівку на те, які таблиці потрібно індексувати, і як їх слід індексувати, але також потенційно можуть використовувати методи розподілу даних.


3

Я б пішов так далеко, щоб сказати, що ніколи не бачив, щоб хтось використовував конструктор візуальних запитів.

Я сам ніколи цього не використовував.


2

Коли я не дуже добре знаю схему, я схильний використовувати конструктор запитів. Це допомагає мені вивчити схему. Пізніше ... друкувати набагато швидше, ніж малювати.


1

Я б ніколи не думав використовувати дизайнера для написання запитів. Я знаю свої схеми баз даних дуже докладно (а в наших базах даних сотні таблиць) і не потрібно думати про те, як приєднатися до них, я просто набираю і запити надходять.


0

Я пишу всі свої запити вручну. Візуальні дизайнери здебільшого лише сповільнюють вас під час сканування сотень таблиць, щоб їх красиво представити. Просте заповнення імен стовпців та імен таблиць, а також довідник посібника для вашої конкретної БД - це все, з чим потрібно працювати.

Зауважте, що мій досвід роботи з дизайнерами візуальних запитів обмежений інструментами, що працюють з базою даних Oracle.


0

Я написав багато SQL та PL / SQL-код, не використовуючи дизайнера запитів. Для тих, хто знає SQL, використання цих інструментів є лише громіздким. Це було б так, як малювати блок-схеми у visio та дозволяти інструменту генерувати програму, а не писати програму.


0

Початківці починають з дизайнера, і занадто часто там були створені перші пробіги SQL-коду. Це виглядає занадто заплутано, оскільки воно не сформовано структуровано / зрозуміло. Зрештою вам потрібно буде перейти на кодування тексту, і вам доведеться все випрямити. Форматування вимкнено. Компанія Intellisense зробила шлях до створення письменників. Я починаю займатися одним із таких, оскільки працюю з новою базою даних.


Я знаходжу, що Intellisense сповільнює мене, тому я його вимкнув.
HLGEM

0

За минулий рік я написав тисячі рядків Oracle SQL та PL / SQL. Більшу частину часу я просто запускаю SqlPlus у вікні оболонки Emacs. Я налаштував доповнення слів, що робить його дуже ефективним. Дизайнер запитів просто сповільнить мене. Якщо мені доведеться переглянути великий набір результатів, тоді я відкрию SqlDeveloper, але намагаюся цього не робити, оскільки це повільно, і хоча він може завершувати імена на основі схеми, все одно швидше працювати в Emacs.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.