vitus_wagner: My photo 2005 (Default)
vitus_wagner ([personal profile] vitus_wagner) wrote2020-01-05 09:37 pm

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

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

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

[personal profile] yurikhan 2020-01-06 08:16 am (UTC)(link)

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

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», впрочем, эту проблему снимает. Если, конечно, нас устраивает иммутабельность объектов.

livelight: (Default)

[personal profile] livelight 2020-01-06 09:08 am (UTC)(link)
Особенно это доставит радости, если надо делать агрегаты над проекцией. Например, count или sum.
yurikhan: (Default)

[personal profile] yurikhan 2020-01-06 09:20 am (UTC)(link)
В моём случае результатом проекции был путь к файлу, над которым нужно было делать дорогостоящую (по процессору и I/O) обработку. И делать её один раз гораздо приятнее, чем 120 (хотя последнее и было безопасно).
livelight: (Default)

[personal profile] livelight 2020-01-06 11:12 am (UTC)(link)
А вот для этого уже существуют взрослые СУБД: чтобы они сами думали, как выполнить 1 раз вычисления, которые, если в лоб выполнять написанное в запросе, придётся делать 120 раз. Но если автоматом схлопнуть все дубликаты, то проблемы будут уже с корректностью, а не производительностью.
livelight: (Default)

[personal profile] livelight 2020-01-06 05:27 pm (UTC)(link)
Альтернатива - написать запрос на том же питоне, но включив мозг самостоятельно и явно указав, что в каком порядке вычислять, дабы оно вычислялось 1 раз, а не 120. Ну или вообще забить, в пределах мегабайта авось никто и не заметит на современном железе.
livelight: (Default)

[personal profile] livelight 2020-01-06 12:29 pm (UTC)(link)
Дык, реляционная алгебра говорит, что результат должен быть одинаков. Потому что дубликаты она не удаляет.
livelight: (Default)

[personal profile] livelight 2020-01-06 05:31 pm (UTC)(link)
Хм, и правда ж. Притом я ни минуты не сомневался, что "настоящая" алгебра отношений работает именно с такими множествами (где операция union all, например, смысла не имеет в принципе), но был уверен, что модель, с которой работает любая "реляционная" СУБД (с дубликатами, union all, select count group by и т.д.) как раз и называется "реляционной алгеброй"

[personal profile] bowhill 2020-01-06 07:56 pm (UTC)(link)
Потому что на практике дубликаты в данных могут возникнуть только в результае ошибок ввода.

Это странное заблуждение, к тому же уникальность элементов набора -- это свойство области предметной области, а не области схемы БД.
Edited 2020-01-06 19:58 (UTC)