Питонистическое.

[vitus_wagner]

Выяснил что в стандартной библиотеке питона модуль collections, а в нем функция namedtuple. Позволяющая генерировать наборы данных с именованными полями и нулевым оверхедом. Более того named tuples - hashable, т.е. могут использоваться в качестве индекстов dict или элементов множества. И их очень удобно создавать из списков, dictionaries и тому подобных конструкций.

Теперь хочу реализацию операций реляционной алгебры над set of named tuples.

Comments

[vitus_wagner]

Потому что на практике дубликаты в данных могут возникнуть только в результае ошибок ввода.
Работать с данными все равно имеет смысл начиная с 1НФ, а вот там как разу уже дубликатов не будет.

Опять же, пересечение, объединение и симметрическая разность - очень полезные операции.

[yurikhan]

Дубликаты в данных легко и непринуждённо образуются в результате неаккуратной реализации проекции.

managers = [e.manager for e in employees]
assert (sorted(m.name for m in managers) ==
        sorted(set(m.name for m in managers)))  # fails

Допущение «set of named tuples», впрочем, эту проблему снимает. Если, конечно, нас устраивает иммутабельность объектов.

[vitus_wagner]

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

И в случае если данные у нас живут в памяти командно-строчного скрипта, ограничение на иммутабельность, как правило, не мешает. При старте прочитали с диска, обработали, построили рядом со старой новую копию, сохранили. (впрочем, в моем случае модифицировать придется не данные, а те объекты, о которых они. А метаинформацию в пригодном для чтении виде мне сгенерят внешние инструменты).

[livelight]

Особенно это доставит радости, если надо делать агрегаты над проекцией. Например, count или sum.

[yurikhan]

В моём случае результатом проекции был путь к файлу, над которым нужно было делать дорогостоящую (по процессору и I/O) обработку. И делать её один раз гораздо приятнее, чем 120 (хотя последнее и было безопасно).

[livelight]

А вот для этого уже существуют взрослые СУБД: чтобы они сами думали, как выполнить 1 раз вычисления, которые, если в лоб выполнять написанное в запросе, придётся делать 120 раз. Но если автоматом схлопнуть все дубликаты, то проблемы будут уже с корректностью, а не производительностью.

[vitus_wagner]

Любит народ у нас стрелять из пушки по воробъям.
Данные размером меньше мегабайта обрабатывать во "взросллой СУБД", одностраничные служебные записки писать в полнофункциональном офисном пакете и так далее.

[livelight]

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

[vitus_wagner]

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

[livelight]

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

[vitus_wagner]

Это где это она такое говорит?

Вот я сейчас бегло пробежался по источникам, и там наоборот, говорят:

Основные свойства отношения:

В отношении нет двух одинаковых элементов (кортежей).
Порядок кортежей в отношении не определён.
Порядок атрибутов в заголовке отношения не определён.

а также

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

[livelight]

Хм, и правда ж. Притом я ни минуты не сомневался, что "настоящая" алгебра отношений работает именно с такими множествами (где операция union all, например, смысла не имеет в принципе), но был уверен, что модель, с которой работает любая "реляционная" СУБД (с дубликатами, union all, select count group by и т.д.) как раз и называется "реляционной алгеброй"

[bowhill]

Потому что на практике дубликаты в данных могут возникнуть только в результае ошибок ввода.

Это странное заблуждение, к тому же уникальность элементов набора -- это свойство области предметной области, а не области схемы БД.