Делаем groupby по двум вычисляемым значениям, соответствующего индекса нет, максимум можем рассчитывать на статистику.
Что вы называете строками-группы?
Не совсем так, с lambda функциями мне нужна только память под счетчики попаданий (я ведь гистограмму строю).
В случае groupby через хэш — под идентификаторы строк.
Конечно. Но в этом и прелесть lambda функций что я пишу код, который актуален только здесь и сейчас. Мне не нужен общий случай.
Если исходя из структуры данных я ЗНАЮ, что двумерный массив подойдёт, использую его, иначе хэш.
Тем что этот хэш строится на моём компе и никому не мешает :)
На самом деле, хэш — это отличный вариант, к сожалению SQL процессор не всегда может сообразить что можно построить именно хэш, а не временный индекс.
А в варианте с lambda функциями даже и хэш не нужен, можно обойтись двумерным массивом.
Либо хэш, либо сортировка, я так и написал.
Если у вас нет оперативной памяти на хранение всех идентификаторов строк,
что происходит при организации хэша,
без сортировки не обойтись.
INSERT INTO foo (auto,text)
VALUES(NULL,'text'); # generate ID by inserting NULL
INSERT INTO foo2 (id,text)
VALUES(LAST_INSERT_ID(),'text'); # use ID in second table
имели ввиду, когда говорили, что «создание нескольких таблиц связанных по IDENTITY… в MySQL можно воспроизвести буквально»?
Но это же совсем не то. Вся эта конструкция держится на доверии. На том, что прикладной программист всё сделает правильно. Правильно вставит, нигде не ошибётся, никто не полезет в таблицу вставлять/удалять грязными руками.
Фильтрацию по индексу одной таблицы и использование значений из другой без join-а не организуешь. Сумеет ли оптимизатор всегда распознать, что первую таблицу поднимать не надо?
Constraints уровня объединённой таблицы нетривиальны и остаются на совести разработчика.
Всё это детали реализации, которыми разработчика загружать не надо,
для него это должна быть одна таблица с общими индексами и общими constraints.
Этот вариант с MySQL напоминает обслуживание паровых машин до изобретения автоматического предохранительного клапана.
1) про «несколько таблиц связанных по IDENTITY/ROWID».
Конечно, так можно сделать. Конечному разработчику проще иметь дело с одной таблицей, которая где-то внутри разбита на ленты и деталей знать не надо. Не нужно следить за тем, чтобы ключи не рассогласовались. Не нужно всё обставлять скобками транзакций, если возникает например 3 insert-а вместо одного. Если я хочу в триггере использовать значение колонки из дружественной таблицы, просто беру и использую. Индексы относятся ко всем колонкам, не надо организовывать join-ы.… Разве нет?
Опять же в тексте есть ссылка на статью «ColumnStores vs. RowStores: How Different Are They Really?». В ней пытаются эмулировать колоночные таблицы в обычной СУБД. Один из основных выводов — эмуляция не даёт нам понять, есть преимущества или нет.
2) «Производительность этой схемы прежде всего зависит от отношения селектов/апдейтов, в том числе для отдельных полей». Да, это тема для будущих статей. Работа в процессе и я не готов делиться результатами.
3) Мне бы не хотелось соревноваться с колоночными СУБД на их поле. Один из вложенных в статью смыслов (не знаю, насколько удалось) в том, чтобы показать, что есть смежная зона, где можно получить преимущества обоих подходов.
PS: в статье честно сказано, что фактически новизна лишь в способе подачи подсказок SQL-процессору.
PPS: автор вероятно «не достаточно осведомлен», но для этого и существует площадка Хабра,
чтобы делиться мнениями и идеями, где можно встретить людей со знаниями в самых разных областях.
Не не, это совершенно разные задачи.
Здесь речь о таблице с большим число записей (и колонок), минимизируем стоимости и создания такой таблицы и поиска по ней с фильтрацией.
Так нужны индексы или нет? Подвижность вашей позиции удивляет. Сначала для вас приемлемо лишнее чтение,
потом вы собираетесь идентификаторы всех частей записи записывать в индексах. Теперь и индексы не нужны.
Самое время продемонстрировать хоть какие-то преимущества графового подхода. Сейчас я вижу одни только издержки.
— размер ячейки 100 x 100
SELECT
count(), round(x, -2) AS cx,
round(y, -2) AS cy
FROM samples GROUP BY cx, xy
Что вы называете строками-группы?
При построении гистограммы она константа, при groupby через хэш — зависит от размера выборки.
В случае groupby через хэш — под идентификаторы строк.
Если исходя из структуры данных я ЗНАЮ, что двумерный массив подойдёт, использую его, иначе хэш.
На самом деле, хэш — это отличный вариант, к сожалению SQL процессор не всегда может сообразить что можно построить именно хэш, а не временный индекс.
А в варианте с lambda функциями даже и хэш не нужен, можно обойтись двумерным массивом.
сделать GROUP BY по двум вычисляемым значениям.
Предложите алгоритм.
Если у вас нет оперативной памяти на хранение всех идентификаторов строк,
что происходит при организации хэша,
без сортировки не обойтись.
Но это же совсем не то. Вся эта конструкция держится на доверии. На том, что прикладной программист всё сделает правильно. Правильно вставит, нигде не ошибётся, никто не полезет в таблицу вставлять/удалять грязными руками.
Фильтрацию по индексу одной таблицы и использование значений из другой без join-а не организуешь. Сумеет ли оптимизатор всегда распознать, что первую таблицу поднимать не надо?
Constraints уровня объединённой таблицы нетривиальны и остаются на совести разработчика.
Всё это детали реализации, которыми разработчика загружать не надо,
для него это должна быть одна таблица с общими индексами и общими constraints.
Этот вариант с MySQL напоминает обслуживание паровых машин до изобретения автоматического предохранительного клапана.
Конечно, так можно сделать. Конечному разработчику проще иметь дело с одной таблицей, которая где-то внутри разбита на ленты и деталей знать не надо. Не нужно следить за тем, чтобы ключи не рассогласовались. Не нужно всё обставлять скобками транзакций, если возникает например 3 insert-а вместо одного. Если я хочу в триггере использовать значение колонки из дружественной таблицы, просто беру и использую. Индексы относятся ко всем колонкам, не надо организовывать join-ы.… Разве нет?
Опять же в тексте есть ссылка на статью «ColumnStores vs. RowStores: How Different Are They Really?». В ней пытаются эмулировать колоночные таблицы в обычной СУБД. Один из основных выводов — эмуляция не даёт нам понять, есть преимущества или нет.
2) «Производительность этой схемы прежде всего зависит от отношения селектов/апдейтов, в том числе для отдельных полей». Да, это тема для будущих статей. Работа в процессе и я не готов делиться результатами.
3) Мне бы не хотелось соревноваться с колоночными СУБД на их поле. Один из вложенных в статью смыслов (не знаю, насколько удалось) в том, чтобы показать, что есть смежная зона, где можно получить преимущества обоих подходов.
PS: в статье честно сказано, что фактически новизна лишь в способе подачи подсказок SQL-процессору.
PPS: автор вероятно «не достаточно осведомлен», но для этого и существует площадка Хабра,
чтобы делиться мнениями и идеями, где можно встретить людей со знаниями в самых разных областях.
Здесь речь о таблице с большим число записей (и колонок), минимизируем стоимости и создания такой таблицы и поиска по ней с фильтрацией.
Если конечно не заниматься схоластикой.
В схеме «звезда» тоже порядок отсутствует, есть правда центральное звено, но это еще как-то можно интуитивно оправдать.
что ваш подход может предложить такого, чего нельзя достичь обычными средствами.
Упорядоченность возникает в тот момент, когда вам надо обойти цикл.
потом вы собираетесь идентификаторы всех частей записи записывать в индексах. Теперь и индексы не нужны.
Самое время продемонстрировать хоть какие-то преимущества графового подхода. Сейчас я вижу одни только издержки.