frameworks учить - Почему нет любви к SQL?




статьи <% (25)

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

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

Что делает SQL настолько страшным, и почему слои абстракции базы данных ценны?


Answers

Хотя SQL действительно выполняет свою работу, у него, безусловно, есть проблемы ...

  • он пытается одновременно быть высоким уровнем и абстракцией низкого уровня , и это ... странно. Возможно, это должны были быть два или более стандартов на разных уровнях.
  • это огромный провал в качестве стандарта . Многие вещи идут вразрез с тем, что стандарт либо движется во всём, либо требует слишком много реализаций, либо слишком мало, либо по какой-то причине не выполняет частично социальную цель, побуждающую продавцов и разработчиков создавать строго соответствующие совместимые полные реализации. Вы, конечно же, не можете сказать, что SQL это сделал. Посмотрите на некоторые другие стандарты и обратите внимание, что успех или неудача стандарта явно является фактором полезного сотрудничества:
    • RS-232 ( Плохое , не достаточно точное, даже то, что штырь передает и какой штырь получает, является необязательным, sheesh. Вы можете выполнить, но ничего не достигли. Шанс успешного взаимодействия: действительно низкий, пока IBM PC не станет де-факто полезным стандартом .)
    • IEEE 754-1985 Floating Point ( Bad , overreach: not a single supercomputer or scientific workstation or RISC microprocessor ever adopted it, although eventually after 20 years we were able to implement it nicely in HW. At least the world eventually grew into it.)
    • C89, C99, PCI, USB, Java ( Good , whether standard or spec, they succeeded in motivating strict compliance from almost everyone, and that compliance resulted in successful interoperation.)
  • it failed to be selected for arguably the most important database in the world . While this is more of a datapoint than a reason, the fact that Google Bigtable is not SQL and not relational is kind of an anti-achievement for SQL.

SQL - действительно хороший язык для обработки данных. С точки зрения разработчика, мне не нравится, что изменение базы данных не прерывает ваш код во время компиляции ... Поэтому я использую абстракцию, которая добавляет эту функцию по цене производительности и, возможно, выразительности языка SQL , потому что в большинстве приложений вам не нужен весь материал SQL.

Другая причина, почему SQL ненавидит, - это реляционные базы данных.

Теорема CAP становится популярной:

Какие цели вы хотите использовать в системе с общими данными?

  • Сильная согласованность: все клиенты видят один и тот же вид, даже при наличии обновлений
  • Высокая доступность: все клиенты могут найти реплику данных даже при наличии сбоев
  • Допуск на разделение: свойства системы сохраняются, даже если система разделена

Теорема утверждает, что вы всегда можете иметь только два из трех свойств CAP одновременно

Адрес реляционной базы данных Сильная согласованность и разделение-терпимость.

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

Если реляционная база данных отклоняется, SQL также отклоняется.


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

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

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

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


Я не скажу, что это ужасно. Это не подходит для некоторых задач. Например: вы не можете написать хороший процедурный код с SQL. Я когда-то был вынужден работать с множеством манипуляций с SQL. Мне потребовались целые выходные, чтобы понять это.

SQL был разработан для реляционной алгебры - вот где его следует использовать.


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

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


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

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


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


Жизнь с чистым SQL действительно может быть адским обслуживанием. Для меня самым большим преимуществом ORM является способность безопасно реорганизовать код без утомительных процедур рефакторинга «DB». Существуют хорошие рамки модульного тестирования и инструменты рефакторинга для языков OO, но я все же должен видеть, например, экземпляр Resharper для SQL.

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


SQL отлично подходит для определенных задач, особенно для обработки и извлечения наборов данных.

Однако SQL отсутствует (или только частично реализует) несколько важных инструментов для управления изменениями и сложностью:

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

  • Полиморфизм : если вы хотите выполнить одну и ту же операцию в разных таблицах, вам нужно дважды написать код. (Можно смягчить это с помощью творческого использования представлений.)

  • Контроль видимости : нет стандартного механизма SQL для скрытия фрагментов кода друг от друга или группировки их в логические единицы, поэтому каждая таблица, процедура и т. Д. Доступна из любого другого, даже если это нежелательно.

  • Модульность и версия

Наконец, ручное кодирование CRUD-операций в SQL (и запись кода для его подключения к остальной части приложения) повторяется и подвержено ошибкам.

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


Слышал много недавно? Надеюсь, вы не путаете это с движением NoSql. Насколько мне известно, это, в основном, группа людей, которые используют NoSql для веб-приложений с высокой масштабируемостью и, похоже, забыли, что SQL является эффективным инструментом в сценарии «высокомасштабируемого веб-приложения».

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


SQL основан на теории множеств, в то время как большинство языков высокого уровня объектно ориентированы в наши дни. Программисты объектов обычно любят думать об объектах и ​​вынуждены мысленно переключиться на использование инструментов на основе набора для хранения своих объектов. Как правило, гораздо более естественно (для программиста OO) просто вырезать код на выбранном им языке и делать что-то вроде object.save или object.delete в коде приложения вместо того, чтобы писать sql-запросы и вызывать базу данных для достижения тот же результат.

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


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

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

SQL замечательный. Слои абстракции над ним делают его еще более значительным!


• Каждый поставщик расширяет синтаксис SQL в соответствии с их потребностями. Поэтому, если вы делаете довольно простые вещи, ваш код SQL не переносится.

• Синтаксис SQL не является ортогональным; например, операторы select, insert, update, и delete имеют совершенно другую синтаксическую структуру.


SQL получает badmouthed из нескольких источников:

  • Программисты, которым не нравится ничего, кроме императивного языка.
  • Консультанты, которые ежедневно сталкиваются со многими несовместимыми продуктами на базе SQL
  • Поставщики нереляционных баз данных, пытающиеся разбить улов реляционных баз данных на рынке
  • Специалисты реляционной базы данных, такие как Chris Date, которые рассматривают текущие реализации SQL как недостаточные

Если вы придерживаетесь одного продукта СУБД, то я определенно соглашусь с тем, что SQL DB более универсальны и имеют более высокое качество, чем их конкуренция, по крайней мере, пока вы не нанесете встроенный в модель барьер масштабируемости. Но вы действительно пытаетесь написать следующий Twitter, или просто пытаетесь сохранить и упорядочить некоторые учетные данные?

Критика SQL часто выступает за критику RDBMS. То, что критики RDBMSes, похоже, не понимают, заключается в том, что они довольно хорошо справляются с огромным классом вычислительных задач и что они здесь, чтобы сделать нашу жизнь проще, а не сложнее.

Если бы они серьезно относились к критике самого SQL, они бы вернули усилия, такие как Tutorial D и Dataphor.


Я бы сказал, что уровень абстракции базы данных, включенный в структуру, хорош, потому что он решает две очень важные проблемы:

  1. Он сохраняет код разным. Поместив SQL на другой уровень, который, как правило, очень тонкий и должен делать только основы для запросов и передачи результатов (стандартным образом), вы сохраняете приложение без помех SQL. По той же причине веб-разработчики (должны) помещать CSS и Javascript в отдельные файлы. Если вы можете избежать этого, не смешивайте языки .

  2. Многие программисты просто плохо используют SQL. По какой-то причине большое количество разработчиков (особенно веб-разработчиков), похоже, очень или очень плохо используют SQL или RDBMS в целом. Они обрабатывают базу данных (и SQL по расширению) в качестве грязного маленького посредника, которому они должны пройти, чтобы добраться до данных. Это приводит к крайне плохо продуманным базам данных без индексов, таблиц, уложенных поверх таблиц в сомнительных манерах, и очень плохо написанных запросов. Или, что еще хуже, они стараются быть слишком общими (экспертная система, кто-нибудь?) И не могут разумно связать данные каким-либо значимым образом.

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


SQL имеет много недостатков, как указывают некоторые другие плакаты. Тем не менее, я предпочитаю использовать SQL по многим инструментам, которые люди предлагают в качестве альтернатив, потому что «упрощения» часто сложнее, чем то, что они должны были упростить.

Моя теория заключается в том, что SQL был изобретен кучкой синих лыжников из слоновой кости. Вся непроцедурная структура. Звучит здорово: скажите мне, чего вы хотите, а не как вы хотите это сделать. Но на практике часто проще просто делать шаги. Часто это похоже на попытку дать инструкции по обслуживанию автомобилей, описав, как машина должна работать, когда вы закончите. Да, вы могли бы сказать: «Я хочу, чтобы автомобиль снова получил 30 миль на галлон, и бежать с этим жужжащим звуком, подобным этому ... хмммм ... и т. Д.». Но не было бы легче, чтобы просто скажите: «Замените свечи зажигания»? И даже когда вы выясняете, как выражать сложный запрос в непроцедурных терминах, механизм базы данных часто сталкивается с очень неэффективным планом выполнения, чтобы добраться туда. Я думаю, что SQL будет значительно улучшен за счет добавления стандартизованных способов сказать, какую таблицу следует читать первым и какой индекс использовать.

И обращение с нулями сводит меня с ума! Да, теоретически это должно было звучать здорово, когда кто-то сказал: «Эй, если значение null означает« неизвестно », то добавление неизвестного значения к известному значению должно дать неизвестное значение. В конце концов, по определению, мы понятия не имеем, что такое неизвестное значение «. Теоретически, абсолютно верно. На практике, если у нас 10 000 клиентов, и мы точно знаем, сколько денег нам нужно 9,999, но есть вопрос о сумме задолженности последней, и руководство говорит: «Какова наша общая дебиторская задолженность?», Да, математически правильная Ответ: «Я не знаю». Но практический ответ: «мы вычисляем $ 4 327 287,42, но одна учетная запись находится под вопросом, чтобы число не было точным». Я уверен, что менеджменту было бы гораздо лучше, если бы не определенное количество, чем пустой взгляд. Но SQL настаивает на этом математически нетронутом подходе, поэтому каждая операция, которую вы делаете, вам нужно добавить дополнительный код для проверки нулей и обработки их специальных.

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


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

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

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

... причина, о которой я только что описал выше.

Уровни базы данных ничего не добавляют , они просто ограничивают вас. Они делают запросы более простыми, но не более эффективными.

По определению, в слоях базы данных нет ничего, кроме SQL .

Что делает SQL настолько страшным, и почему слои абстракции базы данных ценны?

SQL - хороший язык, однако для его работы требуется чередование мозга.

Теоретически SQL является декларативным, то есть вы заявляете, что хотите, и двигатель обеспечивает его самым быстрым способом.

На практике существует много способов сформулировать правильный запрос (то есть запрос, который возвращает правильные результаты).

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

Тем не менее, некоторые люди ожидают, что оптимизатор будет создавать «наилучший возможный план», а не «лучший план, доступный для этого запроса с данной реализацией SQL движка».

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

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

Было бы неплохо, однако, если бы поставщики предоставили некоторый низкоуровневый доступ к таким функциям, как «получить индексный диапазон», «получить строку от rowid » и т. Д., Например, компиляторы C позволили вам встраивать сборку в язык.

Я недавно написал статью об этом в своем блоге:


Там нет любви к SQL, потому что SQL плохо в синтаксисе, семантике и текущем использовании. Я объясню:

  • синтаксис - это кобольская осколка, вся критика кобола применяется здесь (в меньшей степени, чтобы быть справедливым). Попытка быть естественным языком, например, без попытки интерпретировать естественный язык, создает произвольный синтаксис (это DROP TABLE или DROP, UPDATE TABLE, UPDATE или UPDATE IN, DELETE или DELETE FROM ...) и синтаксические монстры, такие как SELECT (сколько страниц делает он заполняется?)
  • семантика также глубоко ошибочна, Date объясняет это очень подробно, но достаточно заметить, что трехзначная логическая логика не очень подходит для реляционной алгебры, где строка может быть или быть частью таблицы
  • наличие языка программирования в качестве основного (и часто единственного) интерфейса к базам данных оказалось действительно плохим выбором и создало новую категорию недостатков безопасности

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

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


Одной из точек слоев абстракции является тот факт, что реализации SQL, как правило, более или менее несовместимы друг с другом, поскольку стандарт немного неоднозначен, а также потому, что большинство поставщиков добавили свои собственные (нестандартные) дополнения. То есть SQL, написанный для базы данных MySQL, может работать не так, как, например, с Oracle DB, даже если он «должен».

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


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

Преимущества огромны. Написание собственных тестов вокруг кода, использование выразительных классов, сильно типизированных наборов данных и т. Д. Мы используем «DAL», который является чистой версией DDD с использованием Generics в C #. Таким образом, у нас есть общие хранилища, единицы выполнения работ (транзакции на основе кода) и логическое разделение. Мы можем делать что-то вроде издевательства над нашими наборами данных с небольшими усилиями и фактически развиваться впереди реализации баз данных. Для создания такой структуры была начальная стоимость, но очень приятно, что бизнес-логика снова стала звездой шоу . Теперь мы используем данные как ресурс и обрабатываем его на языке, который мы изначально используем в коде. Дополнительным преимуществом такого подхода является четкое разделение, которое оно обеспечивает. Например, я больше не вижу запрос базы данных на веб-странице. Да, эта страница нуждается в данных. Да, база данных задействована. Но теперь, независимо от того, где я извлекаю данные, есть одно (и только одно) место, чтобы войти в код и найти его. Возможно, это не большая проблема в небольших проектах, но когда у вас есть сотни страниц на сайте или десятки окон в настольном приложении, вы действительно можете это оценить.

Будучи разработчиком, я был нанят для реализации требований бизнеса с использованием моих логических и аналитических навыков - и наша реализация каркаса позволяет мне быть более продуктивной в настоящее время. Как менеджер, я бы предпочел, чтобы мои разработчики использовали свои логические и аналитические навыки для решения проблем, чем для написания SQL. Тот факт, что мы можем построить целое приложение, которое использует базу данных, не имея базы данных, до ближайшего конца цикла разработки, является прекрасной вещью. Это не означает, что вы стучите против профессионалов базы данных. Иногда реализация базы данных сложнее, чем решение. SQL (и в нашем случае, Views и Stored Procs, в частности) являются абстракцией, где код может потреблять данные как услугу. В магазинах, где есть определенное разделение между данными и командами разработчиков, это помогает устранить сидение в шаблоне удержания, ожидая реализации и изменений базы данных. Разработчики могут сосредоточиться на проблемной области, не зависая над администратором баз данных, и администратор баз данных может сосредоточиться на правильной реализации, если разработчик не нуждается в этом прямо сейчас .


SQL предназначен для управления и запроса данных на основе SET. Он часто используется, чтобы делать больше, и крайние случаи иногда приводят к расстройствам.

Фактическое ИСПОЛЬЗОВАНИЕ SQL может быть затронуто базовым дизайном базы данных, что SQL может не быть проблемой, но дизайн может - и когда вы бросаете в устаревший код, связанный с плохим дизайном, изменения становятся более эффективными и дорогостоящими для внедрения ( никто не хочет возвращаться и «исправлять» вещи, которые «работают» и выполняют задачи)

Плотники могут забивать гвозди молотками, пилить пиломатериалы с пилами и гладкие доски с самолетами. Можно «пилить», используя молотки и самолеты, но это неприятно.


Это отчасти субъективно. Так это мое мнение:

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

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

Другая проблема декларативного языка состоит в том, что некоторые проблемы легче решать императивно. Таким образом, вы либо пишете его на другом языке (вам понадобится стандартный SQL и, возможно, уровень доступа к данным), либо используя специальные языковые расширения поставщика, скажем, путем написания хранимых процедур и т.п. Таким образом, вы, вероятно, обнаружите, что используете один из худших языков, которые вы когда-либо видели, потому что он никогда не был предназначен для использования в качестве императивного языка.

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

Но это правда - нет никаких возможных альтернатив. Поэтому мы все будем использовать SQL в течение следующих нескольких лет.


Для опытного программиста SQL плохие стороны

  • многословие
  • Как многие говорили здесь, SQL является декларативным, что означает, что оптимизация не является прямой . Это похоже на ралли по сравнению с гоночными трассами.
  • Рамки, которые пытаются решить все возможные диалекты и не поддерживают ярлыки ни одного из них
  • Нет простого контроля версий.

Для других причины таковы:

  • некоторые программисты плохо работают на SQL. Вероятно, потому что SQL работает с наборами, а языки программирования работают в объектной или функциональной парадигме. Мышление в наборах (объединение, продукт, пересечение) - это вопрос привычки, которую некоторые люди не имеют.
  • некоторые операции не являются самоочевидными: т.е. сначала не ясно, где и где фильтруют разные наборы.
  • слишком много диалектов

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

[обновление 26.06.10] Недавно я работал с модулем ORM Django . Это единственная достойная база данных SQL, которую я видел. И этот делает работу с вещами много. Однако сложные агрегаты немного сложнее.


SQLServer 2008 теперь имеет тип данных «дата», который содержит только дату без компонента времени. Любой, кто использует SQLServer 2008 и последующие, может сделать следующее:

SELECT CONVERT(date, GETDATE())




sql frameworks