Вот типичная проблема, возникающая в результате «гегемонии SQL»: все данные должны находиться в базе данных, а доступ должен осуществляться через SQL. Это также можно назвать школой программирования «SQL Fetish».
Военная история . В проекте хранилищ данных нам пришлось загружать и обрабатывать организационную иерархию. SQL не делает иерархии хорошо, потому что они могут (и должны) включать соединение неопределенной глубины. Один из администраторов баз данных хотел использовать обход «чистого SQL» по иерархии.
Мое мнение было, что это была пустая трата кода. Мы писали программы на Java. Мы могли бы — тривиально — извлечь все дерево в объекты Java и работать с иерархией как с иерархией.
Администратор БД окончательно «победил» из-за аргумента гегемонии SQL — все права доступа должны быть в SQL, верно? Я говорю «победил», потому что нам в конечном итоге пришлось выбросить весь SQL и использовать плоские файлы. Хранилище данных «чистого SQL» обычно неприемлемо медленно загружается. Подмножества витрин данных могут быть сделаны в чистом SQL, но загрузки не могут.
Последние события . «таблица с именем [
LOTSADATA ], и в ней 14,7 миллиона строк. Один из столбцов в таблице [
LOTSADATA ] —
BRAND », для которой они должны сделать отдельное выделение. «Недостатком [
SELECT DISTINCT ] является то, что ядро базы данных Oracle будет выполнять операции, которые являются безумно дорогой операцией.
LOTSADATA ], и в ней 14,7 миллиона строк. Один из столбцов в таблице [
LOTSADATA ] —
BRAND », для которой они должны сделать отдельное выделение. «Недостатком [
SELECT DISTINCT ] является то, что ядро базы данных Oracle будет выполнять операции, которые являются безумно дорогой операцией.
Вопрос: Существуют ли альтернативные подходы к получению уникальных брендов в
стол?»
Ответ 1.
Дух . Конечно, есть альтернативы. Ты что тупой? У вас есть языки программирования. Используй их.
Ответ 2.
Ты шутишь, верно ? Почему вы спрашиваете меня? Почему бы просто не запустить его? Насколько сложно это сделать? Ты что тупой? Шутки в сторону.
Ответ 3.
Ох . SQL гегемония. Люди на самом деле
спорят о стоимости запроса, и, похоже, никто не может написать восемь строк кода, необходимых для демонстрации того, что
SELECT ALL работает быстрее, чем
SELECT DISTINCT .
[Извините, что назвал вас глупым. Вы парализованы страхом, а не глупостью. Что если SQL не идеальный язык для всех? Если SQL не идеален для всей обработки данных, что еще мы лжем? Это конец организованной обработки данных? Крах западной цивилизации?
Действительно, я неоднократно шокирован, что этот вопрос даже поднимается. И я более шокирован тем, что необходимо использовать аргумент «обращение к власти». Это тривиально измерить. Похоже, что спросить меня легче, чем собирать данные.]
Редактировать . SQL гегемония? Да. Вместо того, чтобы запускать демонстрационную программу, написанную на Java, C # или Python, они спорили о SQL. Выполнение этого с минималистским SQL, казалось, не сделало чей-то радар. Почему бы и нет? SQL гегемония. Вместо того, чтобы рассматривать реальные альтернативы, все были вынуждены искать хитрые хитрости SQL.
Бенчмаркинг . Вот что я сделал. Это 5 строк кода для каждого случая. [Как трудно это может быть? Очевидно, гегемония SQL делает
невозможным даже некоторые организации.]
Результаты .
Для этих данных SQL
SELECT DISTINCT потребовалось почти в 3 раза дольше, чем
SELECT ALL . Это так просто.
Хотите больше скорости? Используйте функции извлечения массива, чтобы получить больше строк в больших буферах.
Это не ракетостроение.
SQL может быть медленным . Не спорьте: эталон. Ваш пробег может меняться.
Базы данных SQL хорошо справляются с блокировкой, управлением транзакциями, резервным копированием, восстановлением и
многими другими вещами. Базы данных SQL полезны и необходимы. Однако SQL не всегда быстрый.
невозможным даже некоторые организации.]
def select_distinct():
q1= db.cursor()
q1.execute( "SELECT DISTINCT BRAND FROM LOTSADATA" )
print q1.fetchall()
q1.close()
def select_all():
q2= db.cursor()
q2.execute( "SELECT ALL BRAND FROM LOTSADATA" )
print set( q2.fetchall() )
q2.close()
Примечания .
- Я только смоделировал 100 000 строк. [У меня нет терпения ждать 15 миллионов строк, которые будут созданы, загружены и опрошены.]
- В таблице было только четыре столбца.
- Я использовал SQLite3 — который в основном находится в оперативной памяти — и работает намного, намного быстрее, чем Oracle.
- Выделить все не является показным результатом, основанным на заполнении кэша; результаты повторяются в любом порядке запросов.
Результаты .
select_distinct 0.417096
select_all 0.162827
Для этих данных SQL
SELECT DISTINCT потребовалось почти в 3 раза дольше, чем
SELECT ALL . Это так просто.
Хотите больше скорости? Используйте функции извлечения массива, чтобы получить больше строк в больших буферах.
Последствия .
Это не ракетостроение.
SQL может быть медленным . Не спорьте: эталон. Ваш пробег может меняться.
Базы данных SQL хорошо справляются с блокировкой, управлением транзакциями, резервным копированием, восстановлением и
многими другими вещами. Базы данных SQL полезны и необходимы. Однако SQL не всегда быстрый.
SQL означает медленный язык запросов . Вам сказали.