Pull to refresh

Comments 13

Уже которая статья из цикла странного программирования на SQL. Возможно, пропустил, но рискну спросить: где это применимо, кроме как в качестве гимнастики для ума?
криптография — там всё что угодно можно применять — в том числе готовые DBMS разработчики который стараются оптимизировать и ускорить запросы.
например для ситуации известности двух из трёх компонент — ключа, исходного текста, шифротекста — например для шифратора с раундовой схемой преобразования — посередине раундов сойдутся прямое и обратное вычисления.
Ммм… и зачем это выполнять именно посредством DBMS?
Кодировать меньше надо и код программы понятен.
Зачем изобретать велосипед для того что в DBMS уже реализовано и очень хорошо реализовано?
Интересно было бы глянуть сравнение реализаций на SQL и на другом каком-нибудь языке общего назначения. Интересуют, прежде всего, такие метрики, как время использования процессора и затраты по памяти. Если по метрикам выяснится, что SQL действительно круче не только потому, что более известен автору — это бы действительно полезно.
Тогда и кодировать больше придётся, чтобы кеши обрабатывать.
Да и задачу надо посложнее — например раундовый шифратор у которого оказалось что первые раунды зависят от половины ключа а последующие от второй половины ключа.
с размером базы данных на 2^32 записей.
в ситуации известен текст и шифротекст — а надо найти ключ.
Собственно, да. Вопрос, аналогичный вопросу ColorPrint. Почему нельзя делать все эти вещи на языке общего назначения? Если нужна эффективность — С или С++, если достаточно простых алгоритмов — чего-нибудь полегче…

П.С.: DBMS в начале прочитал как BDSM в контексте статьи.
Можно если размера памяти хватает — но если данных больше памяти, то туда и дисковое пространство можно использовать под кеширование. И чтобы не изобретать велосипед по сохранению/чтению на/с диск то можно готовую DBMS использовать.
В этом смысле да. Но, на мой взгляд, не хватает обоснования почему именно оперативной памяти начинает не хватать и почему для свопа на диск нужна такая мощная штука, как SQL со всеми её фичами, индексированиям, особенностями размещения в файлах, и.т.д. Неужели какой-нибудь свой легковесный, заточенный под конкретную задачу механизм свопа на диск не будет быстрее?

Сама идея использования SQL для запросов интересная, но так же требует какого-то сравнения. И потом — неужели нельзя применить какие-нибудь методы динамического программирования, чтобы не держать всю таблицу в памяти, а считать её по частям?
а цена и время программирования?
если долго мучится — что-нибудь получится.
естественно любую программу можно преобразовать к эквивалентной в смысле оптимизации — оптимизации могут быть в смысле размера кода или времени выполнения или стоимости труда или количество ресурсов или… — обсуждать можно/неможно бессмысленно если не объявлены приоритеты
машины тьринга, маркова, поста знакомы?
Вот как. То есть я правильно понимаю, что главной метрикой при создании кода для статьи была метрика «время разработки»?
Sign up to leave a comment.

Articles