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

А так вообще есть области где SQL рулит немерянно. Но в вебе такими являются ТОЛЬКО интернет-магазины и то при условии интеграции со складской БД.

(Reply to this) (Thread)

это они тоже любят. это факт.
но беда в том что они любят из статического по смыслу сайта сделать динамический (в полном смысле этого слова) -- "а вдруг юзер захочет отредактировать свой прошлогодний комент и перенести его в соседний трэд?"

(Reply to this) (Parent) (Thread)

Там дело в другом. В принципе, ничего не мешает написать код, который возьмет из html-я коммент и переложит его в другой html. Но вот небольшое изменение в шаблонах потребует перегенерации всех страниц сайта. То есть на этапе разработки дизайна статика обходится дорого. А разработка дизайна web-программистам куда важнее, чем последующая эксплуатация. Заказчикам, кстати, часто тоже.

(Reply to this) (Parent) (Thread)

я вам скажу больше: бывают ТРЕБОВАНИЯ "сделать морду на-лету-сменяемой"
(чем я прям щас собственно и занят...)

(Reply to this) (Parent) (Thread)

Зависит от определения "на лету". Не исключено что раз в полгода перелопатить все страницы окажется дешевле, чем при каждом показе собирать страницу из кусочков.

(Reply to this) (Parent) (Thread)

я конечно сторонник предварительной генерации.
но в тоже время я сторонник ЦЕЛОСТНОСТИ ДАННЫХ.
поэтому источником данных никогда не должен служить сайт -- нужна база данных как надёжный первоисточник.

Но с другой стороны стоят юзеры (кторые порвут меня (нас) на мелкие кусочки (если сделанные ими изменения не вступят в силу за время сравнимое с открытием вкладки в браузере))

В результате этого конфликта сами знаете что....

(Reply to this) (Parent) (Thread)

База данных это плохой источник. Ее нельзя извлечь из кэша гугла, если у тебя навернулся диск на сервере. Далеко не все shared-хостинги предоставляют удобные средства для бэкапа базы данных. И вообще там формат проприетарный, который авторы БД не обещали сохранять от версии к версии.

Поэтому, конечно, необходимо четко понимать, в каком месте у тебя имеется редактируемая мастер-копия данных, а в каких местах - реплики, полученные из данной копии. Но совершенно не обязательно использовать в качестве мастер-копии базу данных.

(Reply to this) (Parent) (Thread)

база данных это хороший источник. (если навернулся кэш гугла) её можно извлечь из книжного шкафа из распечатки дампа в виде SQL.
а диски и ленты это очень плохой источник (потому что формат хранения там проприетарный и никто не обещал его сохранять от версии к версии).

(Reply to this) (Parent) (Thread)

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

А вот насчет лент ты абсолютно прав. У меня валяется в ящике стола несколько DDS-2 кассет. Может там и есть что полезное, но прочитать-то нечем. А ведь десяти лет не прошло с тех пор как они были записаны.

(Reply to this) (Parent)

так могли бы начинаться мемуары авторов мускула.
"нам ничего не мешало написать скрипт который ищет в хтмл нужную порцию данных и апдэйтит её, мы написали и оно заработало! ............
............
через 7 лет мы поняли что без транзакций как-то некомфортненько"

(Reply to this) (Parent) (Thread)

Не, они пошли совсем другим путем. Задача "скрипт который ищет в HMTL" это задача "у нас есть статический сайт, который лежит на диске ровно так как отдается пользователю. Надо написать к нему интерфейс для редактирования, так чтобы он был для редактирующего не менее удобен, чем современные CMS-ки". Кстати, в 80% случаев на транзакции при этом можно забить. Обойтись блокировкой на уровне страниц.

(Reply to this) (Parent)

с NoSQL я продлему экстрагировал так:
анацефалы не могут абстрагироваться от программы к данным (к их устройству, отношениям между ними).

и на этом фоне ещё фееричнее выглядят попытки придумать очередной универсальный фрэймворк для разработки приложений. -- получается что от уже готовой и отлаженой абстракции мы отказываемся (давайте писать каждый раз свою Базу Данных (именно это и есть NOSQL)), а там где надо писать свою программу хотим всунуть какой-нибудь магический предмет типо MVC который за нас всё сделает......

(Reply to this) (Parent) (Thread)

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

Но начинать при этом надо с математической модели и языка на котором эта модель выражается. Язык, кстати, не обязательно должен быть одномерным как SQL. Существует равномощный SQL-ю QBE, который двумерен.

Но анацефалы не умеют мыслить словами (и даже диаграммами). Поэтому язык они придумть не могут. В лучшем случае они способны сделать XML-приложение, при этом забыв прописать в схему все требуемые ограничения.

(Reply to this) (Parent) (Thread)

эквивалентность одному очень тривиальному подмножеству SQL я увидел.
а тезис про "двумерность" не понял. что вы называете "размерностью"?

(Reply to this) (Parent) (Thread)

Полный QBE эквивалентен более-менее полному SQL87. Только этот полный QBE мало где был реализован. В Borland Paradox 4.0, например, QBE не позволял сделать join таблицы с самой собой.

Двумерный это значит двумерный. Запись запроса в QBE существенно зарекается не только на то, какие слова справа и слева от данного, но и на то, какие над и под данным.

(Reply to this) (Parent) (Thread)

теперь понял. и понял что это недостаток а не преимущество.
по сравнению с отточенностью SQL этот QBE выглядит просто выродком.
(кроме того) SQL изначально более понятен юзеру из-за близости к естественному языку ((иначе говоря) условности SQL более стары чем условности QBE).

(Reply to this) (Parent) (Thread)

Юзеру, как показывает торжество графических интерфейсов, язык жестов с тыканьем мышкой в окошки более понятен, чем словесное выражение, сколь бы близко к естественному языку оно ни было. А для QBE, во всяком случае в Paradox GUI-предствление было первично, а текстовое, для записи в скрипты - вторично.

Другое дело что юзеры достаточно редко работают с языками запросов напрямую. Я в те времена, когда пользовался Paradox и FoxPro 2.0 для обработки аркинфовских покрытий - исключение. Там были научные задачи. А так с языками запросов обычно работает программист. А вот ему понимать текст уже удобнее, чем рисунок.

"Условности более стары" уже не работает. С тех пор как в общеобразовательных школах перестали преподавать греческий и латынь.

(Reply to this) (Parent) (Thread)

однако же торжество гуёв показывает ещё одну важную вещь (может она и была чьей-то целью?): на этом языке жестов невозможно разговаривать человеку с человеком! -- обмен информацией между людьми НЕИМОВЕРНО затруднён в этой предметной области ныне. (ещё раз думаю (кто-то мог иметь такую цель сознательно))

(Reply to this) (Parent) (Thread)

Как кто мог иметь такую цель сознательно - Билл Гейтс, естественно. Равно как и Стив Джобс и прочие вендоры проприетарного софта. Если в этой предметной области естественно общаться, если код воспринимается как текст на удобопонятном языке, то хрен заставишь людей платить за те фигнюшки, которые нынче на AppStore тыщами продаются. Как мы знаем, даже операционные системы СУБД и компиляторы с легкостью переходят в область общедоступной культуры.

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

(Reply to this) (Parent)

Можно, я немного издалека начну? Не слишком опытному программисту можно объяснять, почему при возможности переполнения (для целых) или потери точности (для вещественных) сумма может зависеть от порядка сложения. Но это имеет смысл объяснять только потому, что даже не слишком опытному программисту очевидно, что нормальная математическая сумма от порядка сложения не зависит. Аналогично в те времена, когда умножение было сильно дороже сложения, а компиляторы делились на оптимизирующие и тупые, можно было объяснять, когда a*a-b*b можно заменить на (a+b)*(a-b), а когда не стоит. Но этот разговор был осмысленным постольку, поскольку собеседнику было очевидно, что математически они эквивалентны. Обычно даже самый неопытный программист знает школьную алгебру.

А вот реляционной алгебры он не знает. Не учили его ей. Не знает именно как алгебры. Перед тем, как изучать, какое эквивалентное преобразование запросов стоит делать, а какое лучше не надо, необходимо понимать (причём на уровне "уверенного владения"), какие запросы алгебраически эквивалентны. Я, кстати, тоже не знаю реляционной алгебры (именно в том смысле, в котором восьмиклассник знает обычную школьную). Надо будет наверстать. Но я хотя бы понимаю, что навёрстывать.

Аналогично Айверсоновский APL и последующие проекты были не попыткой сделать абсолютно не читаемый язык, а наоборот, попыткой ввести удобные обозначения. Такие, чтобы пользователи легко могли заменять одни выражения на другие, выносить за скобки, и так далее. Его исходный учебник (кстати, его недавно выложили на jsoftware где-то в архивном разделе, ссылку потом поищу, если надо) учил не "программированию", а именно алгебре в несколько необычных обозначениях. Я совершенно не уверен, что эти конкретные средства для этого годятся, но важно, что большинство потенциальных пользователей просто не осознали смысла задачи.

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

... Я не приобрёл ещё достаточно невежества ...

(Reply to this) (Parent) (Thread)

/me applauds

(Reply to this) (Parent)