[image]

SQL

 
1 16 17 18 19 20 21 22

yacc

старожил
★★★
yacc>> Для практической задачи она не нужна
Gudleifr> Если будете делать через 2И-НЕ, будет нужна.
Зависит от задачи.

Gudleifr> Вычисляется, но "с учетом очевидных упрощений, сделанных на основании анализа реализаций этих операций" т.е. не вычисляется.
Ибо вся комбинация, которую дает декартово произведение - тупо не нужна.
Это для математики нет понятия затрат - в самой алгебре
   92.0.4515.10792.0.4515.107

cholev

втянувшийся

☠☠
cholev>> Зы. Почему так?
yacc> Оптимизатор
yacc> Выражение @pGcommon/@count можно первым вычислить ибо оно не зависит от результатов выборки

Понятно. Деление на нолль происходит, независимо от того что выборка возвращает 0 записей.
Спасибо
   2222

Gudleifr

опытный

yacc> Зависит от задачи.
Для любой невырожденной - нужна.
Допустим, в таблице записи длиной по N бит. Т.е. всего возможно 2**N вариантов записей. Таблица (множество записей) записывается в виде числа в диапазоне 2**2**N. И именно с этими числами Вы и будете оперировать операциями 2И-НЕ.

yacc> т.е. не вычисляется
Умножение - получение комбинаций полей записей двух таблиц. Для получения соединения это нужно. Нужны не все поля, и не все их значения, и оптимизация должна их обрезать до или в процессе умножения. Но само комбинирование - нужно.
   97.0.4692.9997.0.4692.99

yacc

старожил
★★★
Gudleifr> И именно с этими числами Вы и будете оперировать операциями 2И-НЕ.
Это просто влияет на то, сколько мне элементов 2И-НЕ надо

Gudleifr> Умножение - получение комбинаций полей записей двух таблиц. Для получения соединения это нужно.
Для получение соединения надо только те поля, которые объявлены на равенстве двух таблиц плюс порядковое поле ( RowId ) и не вся комбинация ( это и есть суть декартова произведения - все комбинации ), а только совпадающие.
Результат всегда усеченный, т.е. не является декартовым произведением, а только его подмножеством и зачастую - очень малым подмножеством.
   92.0.4515.10792.0.4515.107

Gudleifr

опытный

yacc> Это просто влияет на то, сколько мне элементов 2И-НЕ надо
Что заведомо делает практическое применение невозможным.

yacc> Для получение соединения надо только те поля... а только его подмножеством и зачастую - очень малым подмножеством...
Я так и написал.

Вы опять переходите в состояние спора ради спора.
   97.0.4692.9997.0.4692.99

yacc

старожил
★★★
Gudleifr> Что заведомо делает практическое применение невозможным.
Еще раз - зависит от задачи.

Gudleifr> Я так и написал.
Только вот это - не декартово произведение в алгебраическом смысле.

Декартово произведение в алгебраическом смысле делается в СУБД только когда это явно просят запросом
В остальных случая делается именно соединение, если есть INNER JOIN
   92.0.4515.10792.0.4515.107
+
-
edit
 

Sandro
AXT

инженер вольнодумец
★☆

Gudleifr> Допустим, в таблице записи длиной по N бит. Т.е. всего возможно 2**N вариантов записей. Таблица (множество записей) записывается в виде числа в диапазоне 2**2**N. И именно с этими числами Вы и будете оперировать операциями 2И-НЕ.

И что? Почему ты считаешь, что нужно запасать операцию на каждый возможный вариант? Так никто не делает. Множество значений просеивают до его вычисления, а не после. Иначе вычислительная техника была бы невозможна. Точнее — бесполезна.
А ты с её помощью всякую ерунду на форум тут пишешь.

А внутре у ней неонка 2И-НЕ! (Ну не только, естественно, но к ней всё сводится при желании)

PS: Не заметил, кому отвечаю. Ой.
   52.952.9
Это сообщение редактировалось 04.02.2022 в 20:57
NL спокойный тип #04.02.2022 20:42  @yacc#04.02.2022 20:41
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★★

yacc> Декартово произведение в алгебраическом смысле делается в СУБД только когда это явно просят запросом


кросс джойн двух таблиц или типа того...
   96.096.0
+
-
edit
 

Gudleifr

опытный

Sandro> ...
yacc> ...
Дальше можете опять без меня.
   97.0.4692.9997.0.4692.99
RU yacc #04.02.2022 21:02  @спокойный тип#04.02.2022 20:42
+
-
edit
 

yacc

старожил
★★★
yacc>> Декартово произведение в алгебраическом смысле делается в СУБД только когда это явно просят запросом
с.т.> кросс джойн двух таблиц или типа того...
Ну да,
скажем

SELECT *
FROM t1
CROSS JOIN t2

или по-старому

SELECT *
FROM t1, t2

Тут будет в чисто виде декартово произведение в алгебраическом смысле
   92.0.4515.10792.0.4515.107

yacc

старожил
★★★
Sandro> А внутре у ней неонка 2И-НЕ! (Ну не только, естественно, но к ней всё сводится при желании)
Причем если задача узкоспециальная, можно скажем сделать под нее контроллер на ПЛИС, который будет делать тоже самое что движок СУБД только напрямую - технически это возможно
   92.0.4515.10792.0.4515.107

yacc

старожил
★★★
yacc> Причем если задача узкоспециальная, можно скажем сделать под нее контроллер на ПЛИС, который будет делать тоже самое что движок СУБД только напрямую - технически это возможно

Кстати, у меня наверное лет 10 назад была такая идея-фикс :

Скажем есть условный АРМ, который работает с БД на файле - ну скажем SQLite
Очевидно, что если структура базы постоянная и есть набор запросов, то при работе мы по факту каждый раз парсим запрос, прогоняем его для составления плана и выполняем тот же самый план.
Почему бы это не скомпилировать ? Особенно выгодно получается это если клиентская программа и не знает про структуру базы - только вызывает хранимые процедуры-запросы.
Скажем
EXEC proc1
EXEC proc2
EXEC proc3

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

Вот от такого до реализации этого в аппаратном виде - совсем недалеко.

Но по факту никому это не нужно. :p
   92.0.4515.10792.0.4515.107
Это сообщение редактировалось 04.02.2022 в 22:18
NL спокойный тип #04.02.2022 23:26  @yacc#04.02.2022 21:15
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★★

yacc> Вот от такого до реализации этого в аппаратном виде - совсем недалеко.
yacc> Но по факту никому это не нужно. :p

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

а план запроса от демографии данных зависит так что нужно статистику пересобирать и план менять. вне СУБД неудобно это хранить. это UDF называется то что ты придумал или типа того.
   96.096.0
RU yacc #04.02.2022 23:57  @спокойный тип#04.02.2022 23:26
+
-
edit
 

yacc

старожил
★★★
с.т.> ну как вариант есть хранимки (SQL) которые компилятся внутри субд и там же хранятся.
А то, что я предлагал - компилируется в dll и тупо линкуется с приложением.
и потом вызывается как С-функция

Скажем
proc1 = GetProcAddress ( hDll, "EXEC_proc1" )
и далее
rc = proc1 ( parаms )

Просто в той же SQLite или in-memory движках нет хранимок.
Понятное дело что многопользовательский сервер их поддерживает и сам и там это не нужно, ну плюс данных много, планы могут меняться.

с.т.> это UDF называется то что ты придумал или типа того.
Не - это скомпилированные в двоичном виде запросы в виде готовом для исполнения.
Понятное дело что в DLL - часть движка, для исполнения плана, но очень малая
Ибо скажем простой запрос типа селекта даже с джоином легко написать и на чистом С
Просто кусок движка умеет работать с индексами, что руками на С писать сложнее, равно как их перестройку
   92.0.4515.10792.0.4515.107

tarasv

аксакал

yacc> Именно поэтому для использования булевой логики для пересчета операций на М ( множество 256 элементов ) требуются сечения/проекции.

Запись числа в другой системе исчисления это не проекция. И шина про которую раньше писалось не осуществляет эту операции. Ее осуществляют логические элементы подающие на шину напряжение.

yacc> Для начала надо определиться - из каких множеств эти числа :)

Если написано только "11+11" то не нужно, есть общепринятые умолчания и при отклонении от них это должно упоминаться явно. И у логических элементов есть свои умолчания и если обсуждается реализация на логических элементах то задача с не двоичными входными сигналами это просто на повеселиться, а не начать ее решать на полном серьезе, потому что эта часть задачи к обсуждаемому вопросу отношения не имеет.

yacc> Булева алгебра определена на конечном множестве из двух элементов.
yacc> Набор из 256 - тоже конечный.
yacc> Тогда нам ничто не мешает представить его как 8-ми мерное векторное пространство из булевых векторов B8.

И точно так-же ничего не мешает представить 256 уровней как один байт. Никаких математических операций при этом не происходит. Это всего лишь форма представления в физическом виде.

yacc> А электроника, как известно, с бесконечностями не работает :p

Гм. "Радиотехника это наука о контактах" и, при определенных условиях, сопротивление разорванного контакта бесконечно. Спектр сигнала отличного от синусоидального бесконечен. Так что радиотехника работает с бесконечностями но, в отличии от математики, не исследует их свойства.

Ну и мое ХО по этому вопросу - математика не использует "базис 2И-НЕ" не потому что им нельзя заменить любые операции над множествами, а потому что практически полезных результатов из этого получить нельзя. При этом сложность возрастает настолько что определение числа 1 по Бурбаки (для полного раскрытия которого до элементарных компонентов, если гугл нам не врет, нужно не меньше 1054 символов) может оказаться только цветочком.
   98.0.4758.8298.0.4758.82

tarasv

аксакал

yacc> Почему бы это не скомпилировать ? Особенно выгодно получается это если клиентская программа и не знает про структуру базы - только вызывает хранимые процедуры-запросы.

Это теоретически может иметь смысл только если оптимизатор статический, работает от структуры БД и ничего не знает про кардиналити и гистограммы.
   98.0.4758.8298.0.4758.82
IM Татарин #05.02.2022 20:57  @yacc#04.02.2022 21:15
+
-
edit
 

Татарин

координатор
★★★★★
yacc> Формально можно один раз прогнать генерацию плана, а потом из этого плана составить функцию на том же С++ - по запросу.
Так а зачем? Что ты на этом выиграешь?
План и есть компиляция, по сути. Того, что имеет смысл компилировать и предобрабатывать. Что ты можешь сэкономить, переведя интерпретации внутренного формата в исполнимый код, если у тебя вся работа - происходит в выборке?
Это гулькины слёзы в океане. Сотни-тысячи инструкций на фоне затрат в миллиарды-триллионы при непосредственной обработке запроса.

Точно имеет смысл помнить планы и кеши для конкретных частых случаев, но наверняка эти, кто жрут на SQL собак оптом, уже подумали о чём-то таком.


...
Я о другом вот думал.
Интересно было бы вогнать SQL-ускорители в хардвару, в те же СХД, чтобы исключить лишнюю беготню данных. Ну, с диска физически так или иначе читать... но пусть он прямо там вот, в кеше винта и сравнивает, оставляя только выбраное по where, допустим. Ессно, при этом ни о какой ФС ОС речи уже не идёт, таблицы хранятся на уровне физики, в своей спец-ФС.

SQL-винчестер, своего рода.
Ему, процессору на винте, не нужно быть ОЧЕНЬ мощным и нести в себе весь функционал SQL, ему нужно только выполнять операции предфильтра, и тут вполне справится контроллер, который сейчас поддерживает кеширование на винте. То есть, всё сводится не к железному, а чисто софтовому проекту. Ну, разве что кое-какой функционал (типа сравнения строк) опционально можно загнать в ПЛИС или ASIC.

Выгоды - очевидны. Внутренняя скорость диска используется более полно, его кэш используется на многие порядки более эффективно, часть вычислений халявно (потому что проц на винте почти не получает дополнительной нагрузки) выносится с ЦПУ сервера, высвобождаются шины и IO, память и контроллер памяти сервера, кеш его ЦПУ. Огромные выгоды в том, что винчестер знает о своей физической структуре: он может минимизировать самую затратную по энергии и времени операцию - перемещение головок (за 5мс перемещения головки можно прочитать и обработать несколько мегабайт данных).
Снимается целый пласт абстракций (и связаных с ними вычислений) в ФС ОС.

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

Потенциально это даёт огромный выигрыш производительности, частично расшивает ЦПУ как узкое место с SQL и даёт просто фантастическую энергоэффективность.

И всё это, в принципе, можно сделать, просто написав соотвествующий софт для контроллера винта. Ессно, необходимо организовать поддержку для начала в ПостгресСиквеле и МайСиквеле (хардварный лейер можно проигнорировать для начала, пустив запросы поверх всех традиционных уровней, инкапсулировав в обычные запросы записи-чтения). Да, проект сложный и трудоёмкий. Но это вполне проект масштаба стартапа в десяток человек.
   98.0.4758.8098.0.4758.80
Это сообщение редактировалось 05.02.2022 в 21:14
RU yacc #05.02.2022 23:57  @Татарин#05.02.2022 20:57
+
-
edit
 

yacc

старожил
★★★
Татарин> Так а зачем? Что ты на этом выиграешь?
Татарин> План и есть компиляция, по сути. Того, что имеет смысл компилировать и предобрабатывать. Что ты можешь сэкономить, переведя интерпретации внутренного формата в исполнимый код, если у тебя вся работа - происходит в выборке?
Это зависит от задачи.
На больших данных - ну то есть те, которые заведомо не влазят в ОЗУ - там действительно дисковые операции будут перевешивать стоимость построения плана, за исключением случаев, когда запросов очень много. Но тут современные коммерческие СУБД устраивают то или иное кэширование скомпилированных планов и/или используются хранимые процедуры.

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

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

Татарин> Я о другом вот думал.
Татарин> Интересно было бы вогнать SQL-ускорители в хардвару, в те же СХД, чтобы исключить лишнюю беготню данных. Ну, с диска физически так или иначе читать... но пусть он прямо там вот, в кеше винта и сравнивает, оставляя только выбраное по where, допустим. Ессно, при этом ни о какой ФС ОС речи уже не идёт, таблицы хранятся на уровне физики, в своей спец-ФС.
Тут ты сам понимаешь в чем существенная проблема - стандартизация.
Ибо одновременно для Оралкла, MS SQL, Постгре или Мускула не сделать - надо согласовывать нижний уровень в т.ч. и для ОС.
А по факту то, что ты описал, вероятнее всего ... уже реализовано в IBM i или в прошлом AS/400 - где СУБД просто встроено в ядро ОС
   92.0.4515.10792.0.4515.107

yacc

старожил
★★★
tarasv> Запись числа в другой системе исчисления это не проекция.
С т.з. алгебры просто есть множества - не знает она ничего про системы счисления

tarasv> И точно так-же ничего не мешает представить 256 уровней как один байт.
Только вот речь шла о минимальном базисе 2И-НЕ, который на булевой логике.
Для него - требуется представление.
Вот представь, у тебя есть входные

byte x,y;
а реализуешь ты операции посредством ф-ии вот с такой сигнатурой bit nand2 ( bit x, bit y )
Нельзя ей без доп. ф-ий работать с байтом.
Именно bit nand2 ( bit x, bit y ) - минимальный базис.
Я просто дополняю - его недостаточно для работы с множествами.

tarasv> Гм. "Радиотехника это наука о контактах" и, при определенных условиях, сопротивление разорванного контакта бесконечно.
Да нет там бесконечного - есть просто очень большое, которым можно на уровне схемы пренебречь и математически, в мат. модели, выразить как бесконечность.

tarasv> Ну и мое ХО по этому вопросу - математика не использует "базис 2И-НЕ" не потому что им нельзя заменить любые операции над множествами, а потому что практически полезных результатов из этого получить нельзя.
Практических результатов для самой же математики :p Нафига для выяснения какой-нибудь компактности или эквивалентности, сводить множества к вектору булевых ? :p
Ну не считая дискретной на ограниченных множествах
   92.0.4515.10792.0.4515.107
Это сообщение редактировалось 06.02.2022 в 00:12

tarasv

аксакал

yacc> Только вот речь шла о минимальном базисе 2И-НЕ, который на булевой логике.
yacc> Для него - требуется представление.
yacc> Вот представь, у тебя есть входные
yacc> byte x,y;
yacc> а реализуешь ты операции посредством ф-ии вот с такой сигнатурой bit nand2 ( bit x, bit y )
yacc> Нельзя ей без доп. ф-ий работать с байтом.
yacc> Именно bit nand2 ( bit x, bit y ) - минимальный базис.
yacc> Я просто дополняю - его недостаточно для работы с множествами.

Достаточно. Не достаточно для привычного аппарата математики потому что математика вообще не знает что такое время и не имеет инструментов чтобы выразить его, а алгебра не знает что такое пространство. Но это не значит что у тех кто работает с физическим миром есть проблемы с решение этой задачи. Последовательная передача битов (время) или шина на 8 бит (пространство) или их комбинация и задача становится тривиальной.

yacc> Да нет там бесконечного - есть просто очень большое, которым можно на уровне схемы пренебречь и математически, в мат. модели, выразить как бесконечность.

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

yacc> Практических результатов для самой же математики :p

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

yacc

старожил
★★★
tarasv> Достаточно.
Математически - нет

tarasv> Но это не значит что у тех кто работает с физическим миром есть проблемы с решение этой задачи. Последовательная передача битов (время) или шина на 8 бит (пространство) или их комбинация и задача становится тривиальной.
Те кто работают с физическим миром, используют МОДЕЛЬ
МОДЕЛЬ является мостом между математикой и решением задачи, и может комбинировать несколько разделов, точнее их подмножеств, математики одновременно.

tarasv> Есть. Сопротивление равно бесконечности если заряд не перешел с одного контакта на другой.
Да не измеряют толком заряды в радиотехнике.
А вот физики смотрят более детально

tarasv> Естественно что для математики. Но это никак не отменяет того факта что технари в физическом мире умудряются...
Я вообще-то вел речь не кто чего умудряется, а как это правильно именно математические.
Реляционная алгебра может вообще ничего не знать ни про двоичные ни про десятичные представления чисел ни про какое другое
   92.0.4515.10792.0.4515.107
Это сообщение редактировалось 06.02.2022 в 09:10

yacc

старожил
★★★
tarasv> Это теоретически может иметь смысл только если оптимизатор статический, работает от структуры БД и ничего не знает про кардиналити и гистограммы.
Множество алгоритмов, выраженных на структурных языках программирования и ООП, реализовано без учета кардинальности и/или гистограмм и даже без индексов.
Причем увидеть тот или иной затык при прогоне данных можно только профайлером
БД позволяет хотя бы на индексах сделать побыстрее без необходимости существенного кодирования - это просто описывается на SQL.
Кроме того SQL оптом работает операциями по множествам, что быстрее перебора при наличии подобных оптимизаций.

Ну вот пример - скажем какой-нибудь apply с лямбда-функцией - просто лаконичный способ записать перебор
   92.0.4515.10792.0.4515.107
+
+1
-
edit
 

tarasv

аксакал

tarasv>> Это теоретически может иметь смысл только если оптимизатор статический, работает от структуры БД и ничего не знает про кардиналити и гистограммы.
yacc> Множество алгоритмов, выраженных на структурных языках программирования и ООП, реализовано без учета кардинальности и/или гистограмм и даже без индексов.

ORM это тупик для любого более менее нагруженного приложения. Их применение оправдано только тем что они позволяют выкатить MVP достаточно быстро. Не взлетело - выкинули и забыли, но если взлетело то это надо срочно переписывать, как минимум R в CRUD. Потому что оптимальные структура БД и оптимальная структура объектов обычно заметно отличаются.

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

Это вопросы которые должен решать архитектор. Когда я вижу в итераторе того что вернул запрос что-то вроде

return orgs.get(order.getOrgId()).getName();  

вместо
return order.getOrgName();  


моя рука тянется к пистолету все что я могу пожелать это читать больше.
   98.0.4758.8298.0.4758.82

16-й

аксакал
★★
yacc> Декартово произведение в алгебраическом смысле делается в СУБД только когда это явно просят запросом

Если бы. С нынешними оптимизаторами, затюнингованными по самые помидоры, все спортивно. Чуть дал ты маху при конфигурировании с оценкой, скажем, многоблочного чтения, и oracle тебе напихает в сложный запрос кучу декартовых произведений там где не просили.
   96.0.4664.4596.0.4664.45
RU 16-й #07.02.2022 11:30  @Татарин#05.02.2022 20:57
+
-
edit
 

16-й

аксакал
★★
Татарин> Выгоды - очевидны. Внутренняя скорость диска используется более полно, его кэш используется на многие порядки более эффективно, часть вычислений халявно ...

Минусы тоже, и они внушительны. Чтение "задающей" последовательности записей в запросе обычно всегда строиться на селективном отборе с использованием индексов. Само where тут вторично. А это уже требует оперативной статистики и метаданных структуры БД. Условие отбора применяется в контексте соединений, в зависимости что там делается, loop, hash (тот или иной), cartesian (мать его), и с учетом предыдущих-последующих действий - нужен ли отсортированный выход соединения или нет. Т.е. оптимизатор должен предварительно пошуршать. И с учетом того, что там за страницы уже в кэше для логических чтений.
Для "винчестера" как-то многовато.
   96.0.4664.4596.0.4664.45
1 16 17 18 19 20 21 22

в начало страницы | новое
 
Поиск
Поддержка
Поддержи форум!
ЯндексЯндекс. ДеньгиХочу такую же кнопку
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru