Здравствуйте, Sinclair, Вы писали:

_>>Чего чего? ) Вот мы храним в блобах некие сложные объекты и хотим получить из БД все строки, в которых одно из полей данного объекта имеет определённое значение. Как будет выглядеть такой запрос в sql БД? ) Естественно не прибегая к нестандартным расширениям, типа json в PostreSQL.
S>

S>select * from values where value like '%"fieldname":"value"%'
S>

S>Кандидатов фильтруем и отбрасываем.


Ты хоть представляешь, сколько времени такая хрень будет выполняться? ) Я даже не говорю про сравнение с индексами по данному полю в nosql БД. Даже без индексов это будет несравнимо. И это главное на самом деле, хотя можно ещё десяток ужасов упомянуть: а что если таких полей несколько (в разных подобъектах), а что если речь идёт об элементе массива, а что если надо проверять не на равенство и т.д. и т.п. И я думаю, что ты прекрасно всё это понимаешь. Так что заявлять подобную чушь — это просто неуважение собеседников на форуме и напрасная трата их времени.

_>>Хранить вектор в блобе — это бред, который подходит только в очень редких случаях, когда с данными не надо делать никаких операций (кстати, по сути как раз случай БД ключ-значений ).
S>У вас раздвоение личности? Вы одной рукой выступаете за хранение вектора в блобе (NoSQL), а другой — против.

Просто документы в nosql — это совсем не блобы. )))

_>>ОК, давай перейдём к практике. Вот допустим возьмём этот форум (rsdn) — сколько раз в год меняется его схема БД? )
S>Не схема, а требования к консистентности. Этот форум уже реализует ACID, поэтому мы не особенно ожидаем усиления требований к консистентности.

Так мы же уже обсудили, что требования к консистентности вполне могут быть соблюдены и nosql БД без транзакций, если говорить о запросах определённого вида. На что было резонно замечено, что при изменение вида запросов можно попасть на ситуацию, когда данная nosql БД уже не позволит сохранять гарантии. Это действительно так. Но я предложил оценить как часто в среднем веб проекте меняется структура БД и соответственно может возникнуть описанная ситуация. Вот берём пример некого форума и смотрим как часто там меняется схема БД. Можно кстати не только rsdn взять, но и готовые известные движки — они же с открытыми исходниками...

_>>Хыхы, ты забываешь самый нормальный вариант, на котором как раз сейчас и работает большая часть веба (правда пока, по историческим причинам, на базе sql, но это меняется) — когда команда этих самых настоящих профи пишет движок (работающий с nosql БД), а потом этот движок используют в готовом виде в тысячах разных проектов.
S>Ну как же. Я вам ровно про этот вариант и толкую — команда самых настоящих профи пишет движок, а потом его используют. Например, MS SQL Server пишут очень грамотные чуваки.
S>Postgres пишут очень грамотные чуваки. А любители рожают уродцев, независимо от количества SQL в них. JSON в Postgres — это правильный NoSQL. XML support в SQL Server — это правильный NoSQL. Поддержка hadoop в SQL Server — это правильный NoSQL.
S>Правильный NoSQL отличается от неправильного тем, что мы начинаем с корректной реализации, и улучшаем её для определённых операций. А не отказываемся нафиг от всего, чтобы потом мучительно переизобретать транзакции на основе CAS и прочую чушь.

Вообще то речь была о другом, но могу и на эту тему высказаться. Нормальный там nosql или нет зависит от количества предоставленных операций на этих данных. Я лично не смотрел этот вопрос в данных СУБД. Но понятно, что если у нас нет операций поиска, модификации, включения в индекс, для каждого внутреннего элемента, то говорить просто не о чем.

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

_>>Собственно про вопросы связанные с распределённостью мы вообще ещё не говорили. Видимо потому, что тут вообще все sql решения в глубокой заднице. Т.е. даже если извратиться и наковырять руками шардинг sql БД, то всё равно никакого аналога инструмента типа map/reduce там не просматривается.
S> Там, вообще-то, местами есть и более эффективные инструменты.

Оооо, будет очень интересно послушать... Какие же у нас имеются инструменты в sql СУБД превосходящие map/reduce, для работы с распределённой (ручной шардинг) БД? )

_>>1. ПО с требованием гарантий, которые плохо ложатся на любую nosql схему. Можно реализовать через:
_>> — slq БД — это их естественная ниша.
_>> — nosql с дополнительной надстройкой реализации ACID, имеет смысл только если становится критически важна автоматическая масштабируемость (т.е. случай огромных сервисов). Для одиночного сервера очевидно менее эффективно sql решения.
S>Для кластера, я вас разочарую, это будет ещё менее эффективно.

Видимо в одноклассниках и т.п. работают исключительно идиоты, не знающие этого замечательного факта. )))

_>>3. ПО без требований гарантий.
S>ПО без требований гарантий можно вообще не реализовывать. Просто на каждый POST ваша форма будет говорить "200 ok", а на каждый GET — "404 Извините, наверное данные ещё не синхронизованы".

Да, да, действительно, зачем было реализовывать поисковые машины гугла, яндекса и т.п. )))

_>>Поведение программы и наличие ACID транзакций в СУБД — это не особо связанные между собой вещи. Можно зафиксировать поведение и сделать к нему десяток разных реализаций (как на базе sql БД, так и на базе nosql).
S>Не надо юлить. Отказ от ACID — это вполне конкретное, наблюдаемое поведение. Вот вы интервьюируете заказчика, он вам рассказывает функциональные требования, вроде "есть функция поиска вариантов размещения в гостинице; на входе — географическая привязка; даты вселения/выселения; набор проживающих — количество взрослых, и возраста для N детей. На выходе — список свободных номеров на эти даты, удовлетворяющих заданным критериям". Вы в какой момент будете его спрашивать "а можно мы будем иногда показывать и номера, не подходящие под запрос"?

Откуда возьмутся неподходящие под запрос номера? )

Здравствуйте, alex_public, Вы писали:

_>Ты хоть представляешь, сколько времени такая хрень будет выполняться?
Конечно представляю. Если данные не влезают в память, то столько же, сколько и в MongoDB, т.к. скорость чтения с диска у всех одинаковая.
_>) Я даже не говорю про сравнение с индексами по данному полю в nosql БД.
А кто мне мешает завести мой индекс поверх блоба? Ведь full text search как-то работает в RDBMS.

_>Даже без индексов это будет несравнимо. И это главное на самом деле, хотя можно ещё десяток ужасов упомянуть: а что если таких полей несколько (в разных подобъектах), а что если речь идёт об элементе массива, а что если надо проверять не на равенство и т.д. и т.п. И я думаю, что ты прекрасно всё это понимаешь. Так что заявлять подобную чушь — это просто неуважение собеседников на форуме и напрасная трата их времени.
Ну вы же на полном серъёзе предлагаете мне привернуть ACID врукопашную к NoSQL базам "в тех редких случаях, когда это надо". Ну вот и я вам отвечаю — в тех редких случаях, когда вам внезапно потребовалось найти что-то в бесструктурных данных, делаете примерно так, как я показал. Ну, предполагая, что ваш выбор RDBMS ограничен теми, которые выпущены до 1990 года, и в них никак нельзя внедрить пользовательские функции.

_>Просто документы в nosql — это совсем не блобы. )))
Вам так кажется.

_>Так мы же уже обсудили, что требования к консистентности вполне могут быть соблюдены и nosql БД без транзакций, если говорить о запросах определённого вида.
Это вы обсудили. Пока что с вами никто не согласился.

_>На что было резонно замечено, что при изменение вида запросов можно попасть на ситуацию, когда данная nosql БД уже не позволит сохранять гарантии. Это действительно так. Но я предложил оценить как часто в среднем веб проекте меняется структура БД и соответственно может возникнуть описанная ситуация.
Вы передёргиваете. Речь не об изменении структуры, а об изменении требований к консистентности. Вот вы запустили свой форум, он на десяти пользователях работал почти как настоящий. А потом попёрла нагрузка, оказалось, что есть артефакты изоляции, народ жалуется. Вы приходите к разработчикам и говорите "у нас тут надо обеспечить, чтобы модерирование удаляло сообщения изо всех мест форума". И тут выясняется, что такие требования к консистентности в нынешней структуре обеспечить невозможно. Структура-то у вас была придумана под более мягкие требования. В SQL этого вопроса даже не возникнет: структура продиктована функциональными требованиями. А вам теперь надо переделывать структуру. Причём не очень понятно как — ведь в вашей СУБД нет способа сделать alter table; просто часть данных валяется в старой структуре, а часть — в новой. И у вас пожизненная обязанность тащить в коде if-ы, которые разбираются с тем, что делать, если выпиливается пост из топика, который был заведён до 1 мая 2015.

_>Вообще то речь была о другом, но могу и на эту тему высказаться. Нормальный там nosql или нет зависит от количества предоставленных операций на этих данных. Я лично не смотрел этот вопрос в данных СУБД. Но понятно, что если у нас нет операций поиска, модификации, включения в индекс, для каждого внутреннего элемента, то говорить просто не о чем.
В некотором смысле да. Но помимо количества есть ещё и качество. Я уже заметил, что вам важно, чтобы "в один запрос". А мне важно, чтобы за минимум IO. Потому что объём кода можно решить — в частности, при помощи внешних инструментов типа linq, помогающих мне генерировать код запроса. А проблемы с IO без трепанации движка решить невозможно.

_>Оооо, будет очень интересно послушать... Какие же у нас имеются инструменты в sql СУБД превосходящие map/reduce, для работы с распределённой (ручной шардинг) БД? )
Ну, например, semantic query optimization. Это когда у меня запрос select * from all_users where name like 'alex%' даже не отправляется на сервера, где хранятся имена, начинающиеся не на al. Когда у меня запрос select top 10 from hotels order by .... выполняет не полный map/reduce, а выполняет на каждом шарде top 10 локально, и потом мерджит результаты. И ещё много всего.

_>Видимо в одноклассниках и т.п. работают исключительно идиоты, не знающие этого замечательного факта. )))
Забудьте про одноклассников. У вас никогда в жизни не встанет ровно их задача. А для вашей задачи придётся всё заново решать.
_>Да, да, действительно, зачем было реализовывать поисковые машины гугла, яндекса и т.п. )))


_>Откуда возьмутся неподходящие под запрос номера? )
Как откуда? Например, полчаса назад забронировали последний номер в отеле. А ваша безгарантийная система всё ещё реплицирует данные, и показывает отель как доступный.

Здравствуйте, gandjustas, Вы писали:
G>Усложняет все IQueryable<T>, так как это универсальный тип и вызов Select невозможно обработать не зная что там внутри IQueryable лежит.
Эмм, так ведь вроде же query comprehension к IQueryable никаким боком?
Можно запросто делать совершенно рукопашный тип, с рукопашным Select. Или ты что сейчас имеешь в виду?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:
G>>Усложняет все IQueryable<T>, так как это универсальный тип и вызов Select невозможно обработать не зная что там внутри IQueryable лежит.
S>Эмм, так ведь вроде же query comprehension к IQueryable никаким боком?
S>Можно запросто делать совершенно рукопашный тип, с рукопашным Select. Или ты что сейчас имеешь в виду?
Это не поможет. Чтобы обработать select нужно знать к чему он применяется. Если запрос, к которому применяется select заранее неизвестен (может быть разный), то и в compile-time обработать не получится. То есть с точки зрения быстродействия свой тип ничего не даст.

Единственное на что можно надеяться, что мс начнет применять более легковесный api вместо рефлексии. Или саму рефлексию сделает быстрой. Большую часть времени работы приложения в обработке linq отнимает именно она и не оптимизируется.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>Я уже третий раз тебе пишу одно и то же. Сегодня ты думаешь что тебе достаточно модификации одного документа, а завтра внезапно становится недостаточно. Все, ты в жопе.

_>Вот "внезапно" не должно быть у нормального проектировщика. Если есть шанс подобного, то и не надо использовать подобный инструмент.
Идеальный мир? Найди любого проектировщика и спроси уверен ли он, что текущая схема покроет требования через год. Все кто ответят да — профнепригодны.

_>Но во многих случаях общая схема полностью очевидна изначально и в дальнейшем меняется только в мелочах (которые кстати в nosql БД обычно остаются где-то на уровне внутренностей json объектов).
А ты сколько систем сделал, что так утверждаешь? Обычно ровно наоборот. Я вот последний год пилю систему, в которой сам заказчик предоставил концептуальную схему БД. И каждый месяц происходят изменения схемы. А там где заказчик не предоставил — каждую неделю меняется.


_>>>Во-вторых во многих таких СУБД имеется реализация CAS, что соответственно позволяет нам сделать эффективную версионность, откаты и т.п. Что может быть даже интереснее банальных транзакций.
G>>Да что ты? Давай покажи как CAS поможет сделать аналог такой операции:
G>>

G>>insert into X values(select count(*) from X)
G>>

G>>MS SQL позволяет сделать так, чтобы в X не было повтоярющихся значений. Давай вперед с CAS сделай это.
G>>Причем это даже возможно, только надо будет свой transaction log сделать и блокировки. И тормозить это будет дико.

_>Там делается не журнал транзакций, а просто версия документа, у каждого своя (и хранится всё в самом документе). И соответственно ты можешь легко цепляться за неё. )
Я видел как это делается. Это ровно журнал транзакций и блокировки. Поле ссылки за объект трназакции это блокировка, а поле хранящее параметры апдейта — журнал транзакций.
Если что для работы не надо хранить весь журнал закоммиченных транзакций, его хранят только для восстановления после сбоя. Ничего нового ты не придумал. Если что тот же самый CAS используется для журналирования в SQL Server и других взрослых движках. Только вот такие транзакции в монге тормозят аццки.
Версионность тут не сильно нужна, её можно и не хранить если бизнес-задачи нет.

_>Кстати, а собственно этот список Х у нас хранится в разных документах или в одном? )))
Естественно в разных. Хранить все в одном документе вообще не вариант, документ распухает, время выборки и апдейта растет.


_>Это не говоря уже о дикой искусственности примера. )))
Да что ты говоришь???
Простой кейс — начисление процентов по кредиту.

insert into operations select creditid, creditformula(sum(value)) as value from operations groupby creditid)

Таких примеров миллион.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

_>>>Это в какой ценовой категории интересно? )
G>>500к-1М рублей
_>Ууу) На нормальные сервисы (без гигантских sql баз) хватает в 10 раз меньшего)))
Ну да, когда данные хранить не надо, то очевидно дешевле будет. Но мы как раз обсуждаем сценарии когда данные хранить надо. Причем много, в 10 больше объемов ОП как минимум.

_>>>Про ресурсы я ничего такого не говорил. Как раз наоборот, nosql БД обычно летают на совсем дохлых серверах. ))) А вот умений программиста с ними действительно надо больше.
G>>Ты опять сравниваешь точечные замеры? Не понял еще что отсутствие гарантий замедляет систему?
_>Это при условие, что ты начнёшь их все восстанавливать в своём коде. Однако я уже не раз писал, что они далеко не всегда нужны.
Они почти всегда нужны. Потому что acid — это в первую очередь бытовое понимание транзакций для людей. И неявно от любой системы они требуют тоже самое.

_>>>Stackowerflow и т.п. — это старые проекты. Потому и работают на РСУБД.
G>>Ты думаешьтам такие лоши работают, что если бы были профит от nosql они бы не отказались от sqlserver?

_>Я думаю, что там нормальные люди, руководствующиеся принципом "работает — не трогай". ) У них же вряд ли намечается какой-то крупный рост нагрузки в ближайшее время. Так с какой стати им тратиться на переход? ) И в большинстве мест всё тоже самое. А вот в стартапах естественно совершенно другой расклад... )
Ты почитай блог. Они дофига изменений проводят постоянно, более того они работают на CTP версиях SQL Server. В стартапах детский сад по сравнению с этими чуваками.

_>>>Речь о текущих стартапах (или уже не совсем стартапах)))).
G>>Вот тебе о стартапах — http://habrahabr.ru/post/231213/ как раз соцсеть с лайками. Прочитай внимательно прежде чем продолжать писать.
_>Хыхы, я эту ссылку уже несколько раз тут видел. ))) И соответственно обсуждение тоже уже было. )))
И?

G>>Ты удивишься, но все инстансы редиса, которые я видел в продакшене имеют отключенный persistance. Не нужен он там.
G>>А memcached — говно, банально нету возможности атомарно увеличить счетчик. Без этого его даже в качестве кеша можно использовать с огромной натяжкой.
_>Ну вот, ты оказывается постоянно используешь nosql решение, правда не совсем по назначению. )))
Ты начинаешь спорить о терминах, чего мне совсем не хочется. Я могу попросить тебя привести дифференцииорующее определение NoSQL, которое позволяет их отделить от SQL систем и ты не сможешь. Его просто не существует. Максимум что ты можешь это перечислить продукты. Но тогда все твои разговоры теряют смысл.
Можем предположить, что ты nosql называешь все что не РСУБД. Тогда почему ты memcached назвал кешем, а не nosql?
Предположим, что ты nosql называешь все что не РСУБД и хранит данные на диске, но тогда мочему redis с отключенным persistance попал в эту категорию?
Чтобы ты сам себя не завел такую ситуацию — давай говорить о юзкейсах:
1) РСУБД — ACID со связями между строками
2) NoSQL — атомарность и надежность в пределах одного документа на одном узле + автошардинг.
3) Кеш — быстро взять\положить по ключу, гарантий никаких.


_>>>ОК, давай, приведи эту https://community.nodebb.org БД в неконсистентное состояние. )))
G>>На каждый пост выполняется около 5 обращений к монге, любое падение и база в неконсистентном состоянии. Кроме того это плохо будет работать с multimaster репликацией, так как при репликации вместо инкремента в базу уходит новое значение и легко потерять значения в счетчике при параллельной записи в два разных мастера. Даже ниче специально делать не нужно, оно само рассинхронизируется. Думаешь почему в монгу добавили autoincrement поля?

_>Нуу так можно увидеть эту "рассинхронизацию" где-то на практике? ) Или у нас по прежнему одни слова будут? )))
Я думаю оно уже рассинхронизировано, счетчики сообщений не сосуществуют реальному количеству. Только как это проверить — хз. Это кстати показательный пример для NoSQL. "нормально" работают системы, данные в которых — мусор.

_>>>Вообще то прямой по моей ссылке в меню можно было найти живое демо. Но я на всякий случай уже дал прямую ссылку в предыдущем абзаце. )))
G>>Еще раз: Покажи живой инстанс с посещяемостью rsdn

_>А ты думаешь там сильно отличается?)
Думаю да.

_>>>Т.е. переводя на русский язык твои кривые намёки, можно сказать, что ты считаешь описанную ситуацию (с преимуществом оптимизации программистами, над заменой железа) редким случаем? )
G>>Я считаю, что такое возникает гораздо реже, чем об этом ты пишешь.
_>Это смотря в какой области и на каком языке. )))
Это в случае тех самых вебов, стартапов, о которых ты пишешь и корпоративном ПО.

Здравствуйте, alex_public, Вы писали:

_>Просто документы в nosql — это совсем не блобы. )))
Как раз совсем блобы. JSON документ это просто строка, BSON как в монге это просто блоб.
Поиск по блобу делается именно как поиск — парсинг документа, сравнение значений и так по всей коллекции.


_>Оооо, будет очень интересно послушать... Какие же у нас имеются инструменты в sql СУБД превосходящие map/reduce, для работы с распределённой (ручной шардинг) БД? )
Ты думаешь там map\reduce от хорошей жизни? Думаешь но прям быстро и эффективно работает? Ты глубоко заблуждаешься.
В монге map-reduce знатный тормоз и ресурсы кушает аки свинья помои. Если ты запустишь map\reduce на несколько шардов с гигабайтными базами, то дожидаться ответа будешь минутами.
Если ты запустишь несколько агрегатных запросов на разные SQL Server, а потом соберешь результаты на клиенте, то это займет доли секунды на таком же объеме баз.
При этом вспомни что я раньше тебе писал. Потребность в шардинге в РСУБД примерно на два-три порядка (в 100-1000 раз) ниже. Потому что РСУБД не упираются в ОП.
А чтобы каждый раз не бегать по сотне ГБ данных умные люди придумали индексированные\материализованные представления в РСУБД.

Здравствуйте, alex_public, Вы писали:

_>Из SQL БД при определённых раскладах тоже можно очень быстро "достать по ключу" (кстати, насколько я помню как раз такой вариант работы с mysql и использовал когда-то facebook) — это теперь тоже кэш? )
Под "быстро достать" имеется ввиду быстрее чем из основного хранилища. И таки да, известны случаи когда MySQL переделывали для использования в качестве такого кэша, путем отказа от гарантии ACID.
Если же говорить об FB, то там зоопарк разного рода NoSQL для специфических задач в качестве кэша, включая memcache и все это поверх классического SQL в как основного хранилища.

Здравствуйте, alex_public, Вы писали:

_>Соболезную)
Не соболезнуйте, лучше признайтесь, где же тот прекрасный мир с эльфамии единорогами, где требования отливаются в бронзе до начала разработки и не меняются во время жизненного цикла продукта?

Здравствуйте, gandjustas, Вы писали:

G>Большую часть времени работы приложения в обработке linq отнимает именно она и не оптимизируется.

Откуда дровишки?

Здравствуйте, gandjustas, Вы писали:
G>Это не поможет. Чтобы обработать select нужно знать к чему он применяется. Если запрос, к которому применяется select заранее неизвестен (может быть разный), то и в compile-time обработать не получится. То есть с точки зрения быстродействия свой тип ничего не даст.
Ну, это как всегда вопрос выбора между дудочкой и кувшинчиком. Т.е. либо мы имеем точный тип, либо мы имеем возможность собирать его в рантайме.
С другой стороны, имея существующий компилятор, мы ничего не выиграем и от статики — один хрен в select придёт ET, которое генерируется заново на каждый проход через этот select.
G>Единственное на что можно надеяться, что мс начнет применять более легковесный api вместо рефлексии. Или саму рефлексию сделает быстрой. Большую часть времени работы приложения в обработке linq отнимает именно она и не оптимизируется.

Здравствуйте, alex_public, Вы писали:

_>Вот именно, что важна функциональность. И по ней, по своему предназначению, Redis — это СУБД. Не смотря на то, что некоторые ммм специалисты предпочитают использовать его в роли кэша (вместо специально предназначенных для этого инструментов). И разницу в этой функциональности понять очень легко: форумы работающие на Redis'е (без всяких других СУБД) существуют (и кстати летают), а форумов работающих на memcached не существует.
Меня не покидает ощущение, что вы, коллега, придумали себе идеальную картину мира ориентируясь лишь на формальные наименования продуктов, и теперь с усердием достойным гораздо лучшего применения, пытаетесь подогнать окружающую действительность под ваши фантазии в одном отдельно взятом форуме...
Увлекательно, но малопродуктивно.
Так вот, те форумы, которые используют Redis и летают — используют Redis как раз в качестве распределенного кэша поверх классического SQL.

Здравствуйте, VladCore, Вы писали:

VC>Весь критический по требованиям производительности тормозам код приходится переписывать выкидывать с помощью Dapper.
VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Здравствуйте, gandjustas, Вы писали:

G>Единственное на что можно надеяться, что мс начнет применять более легковесный api вместо рефлексии.

Да нет там никакой рефлексии, компилятор напрямую подставляет токены элементов метаданных при вызове CreateXxx. Погляди в IL — там везде последовательность ldtoken + GetXxxFromHandle.

Здравствуйте, Sinclair, Вы писали:

S>Теоретически — можно. Практически — вы получите производительность и TCO в разы хуже.
S>Вы попробуйте хотя бы на пальцах прикинуть, как вы обеспечите ACID в банальном переводе денег со счёта A на счёт Б, не складывая все остатки всех счетов всех пользователей в один документ.
На пальцах всё написали в mongodb — Perform Two Phase Commits. Я как-то рассматривал альтернативные идеи, как можно ускорить обработку финансовых транзакций (чисто абстрактно). Но в итоге понял — что nosql — это точно совсем не наш путь, так как, на фоне нормального SQL — это чистейшей воды мракобесие (а вот альтернативных путей, через SQL — куча, особенно эксплуатируя предметную область).

Здравствуйте, Mamut, Вы писали:

F>> И что за история с real_escape? Реально было?
M>Это реально было PHP поставлялся с mysql_escape_string. Потом оказалось, что он работает неправильно. Поэтому вставили mysql_real_escape_string. И он работает так себе, поэтому они потом наконец осилили параметризованные запросы
Я думал это анекдот. Впрочем там отличия, связаны с кодировкой строк. Но в целом конечно да. Жесть.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Но самый пик маразма это, безусловно, способ задания пейджинга все в том же, емнип, SQL'99. Это который SELECT OVER. Сторонники, сука, чистоты концепции. Слава богу в последнем стандарте сделали почти как надо (FETCH NEXT ...). А совсем как надо — в проприетарном диалекте PGSQL.
Не знаю как в PGSQL, но в погоне за модными конструкциями (FETCH NEXT + OFFSET) тут главное не забывать, что запросы с разными значениями OFFSET / FETCH NEXT — могут и должны получать разные планы — в результате чего резльтаты могут быть неконсистентными (пропущенные строки, особенно между нулевой и первой страницей). Поэтому — если хотим стабильный пэйджинг — или таки SELECT OVER с ROW_NUMBER, или нужна уникальная сортировка.

Здравствуйте, fddima, Вы писали:

F>Поэтому — если хотим стабильный пэйджинг — или таки SELECT OVER с ROW_NUMBER, или нужна уникальная сортировка.

Для нормального пейджинга по любому нужна уникальная сортировка, хоть с SELECT OVER, хоть с FETCH NEXT.

Здравствуйте, Ночной Смотрящий, Вы писали:

F>>Поэтому — если хотим стабильный пэйджинг — или таки SELECT OVER с ROW_NUMBER, или нужна уникальная сортировка.
НС>Для нормального пейджинга по любому нужна уникальная сортировка, хоть с SELECT OVER, хоть с FETCH NEXT.
С тем, что нужна уникальная сортировка, — я вообще не спорил. Недосказал, это есть.
Учитывая, что вообще применение такого рода пэйджинга, — далеко не общий случай (он как минимум не стабилен при модификациях), то и SELECT OVER с ROW_NUMBER вполне себе выбор.

Здравствуйте, fddima, Вы писали:

F> Учитывая, что вообще применение такого рода пэйджинга, — далеко не общий случай (он как минимум не стабилен при модификациях), то и SELECT OVER с ROW_NUMBER вполне себе выбор.

Речь тут не о выборе, а о на редкость уродливом синтаксисе.