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

M>Для «движков» — да. Только буквально в первый же день использования такого движка приложение, которое на нем строится оказывается строго заточено под один определенный движок. По вполне понятным причинам.

Ну если мы говорим про конкретную инсталляцию, то естественно, что после установки она работает только с одной базой — какой смысл прыгать то? ) Главное что в момент инсталляция можно выбрать любую СУБД.

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

_>Ээээ, что? ) Берём первый попавшийся из популярных движков https://www.phpbb.com/about/features/ и смотрим в раздел Data Management — видим все популярные базы данных. И такая ситуация не у одного этого движка, а скорее вообще везде. Естественно там, где люди создают продукт и есть конкуренция. А не как с внутрикорпоративным софтом, где можно написать любой говнокод и всё равно получить деньги, лишь бы он соответствовал ТЗ.

Берём первый попавшийся из популярных движков, самый дырявый из всех, какие только есть.

fixed.

Форумы можно хоть на чем писать. Материальной ответственности они не предполагают. А деньги лучше все же хранить в оракле, mssql или постгресе.

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

M>А потом внезапно окажется, чтофункция реализована неверно, и надо делать sql_real_escape_string и т.п.
M>Это уже пройденные ошибки, зачем их повторять снова?

Так а я как раз нигде и не предлагал работать через sql строки. Соответствующий пример был приведён для сравнения производительности. Проверить насколько работа той библиотечки уступает (если вообще уступает!) решению в лоб. Так что все шутки с инъекциями — это вообще не по теме и похоже приведено народом, который хочет максимально увести разговор от нашей изначальной теме о производительности. )))

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

_>>Ээээ, что? ) Берём первый попавшийся из популярных движков https://www.phpbb.com/about/features/ и смотрим в раздел Data Management — видим все популярные базы данных. И такая ситуация не у одного этого движка, а скорее вообще везде. Естественно там, где люди создают продукт и есть конкуренция. А не как с внутрикорпоративным софтом, где можно написать любой говнокод и всё равно получить деньги, лишь бы он соответствовал ТЗ.

С>Берём первый попавшийся из популярных движков, самый дырявый из всех, какие только есть.
С>fixed.

А это имеет какое-то отношение к нашей дискуссии? ) Или ты думаешь, что если мы возьмём самый защищённый из них, то набор СУБД будет другой? )

С>Форумы можно хоть на чем писать. Материальной ответственности они не предполагают. А деньги лучше все же хранить в оракле, mssql или постгресе.

А с этим тут кто-то спорил? ) Хотя я кстати в последнее время вижу всё больше и больше информации о применений той же MongoDB в финансовых областях.

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

_> Ужас какой. Т.е. в твоих приложениях работа с sql размазана по всем слоям?

Ты до сих пор не можешь понять сути, хотя я много лет назад тебе пытался объяснить что такое линк и зачем он нужен. Нет никакой работы с sql нигде. Есть работа с данными. А вот когда вместо этого начинается "работа с sql", вот тогда надо сушить весла.

_> Да "специалиста" с такими подходами нельзя и на пушечный выстрел подпускать к проектированию архитектуры приложения!
_>Во всех нормальных движках, работа с БД всегда абстрагирована в отдельный тонкий слой, с которым другие слои приложения взаимодействуют уже в терминах самого приложения (а не sql).

Это архитекта, который плодит решения в которых сухогрузы кода, который перекладывает из пустого в порожнее и ничего полезного не делает надо из пушки расстреливать.

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

EP>Пара миллисекунд практически на ровном месте. Да это же 1/50 секунды современного железа!

1/500

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

M>Хотя в целом — да. Сначала надо дойти до состояния, когда пара мсек играют роль А до такого реально доходят немногие (единицы единиц процентов, наверное).

После этого для пары запросов втыкается CompiledQuery и эта ужасная пара миллисекунд убирается.

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

M>А потом внезапно окажется, чтофункция реализована неверно, и надо делать sql_real_escape_string и т.п.
M>Это уже пройденные ошибки, зачем их повторять снова?
Ребят, просвятите по честному — я кажется пропустил.
Ээээ... почему эскейпинг не панацея (при правильной реализации), ну и при условии "нормального" эскэйпинга. Там не знаю, вложенные ескейпы ведь могут драться. Я опускаю такие случаи. Грубо говоря берем:

select * from names where name = ?

(ага адский mysql параметр адын!)
И что за история с real_escape? Реально было?

PS: В mysql я надеюсь уже сделали нормальные параметры? Я имею ввиду, так, как это у других — т.е. не клиентский эскэйпинг, а на уровне протокола?

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

НС>Ты до сих пор не можешь понять сути, хотя я много лет назад тебе пытался объяснить что такое линк и зачем он нужен. Нет никакой работы с sql нигде. Есть работа с данными. А вот когда вместо этого начинается "работа с sql", вот тогда надо сушить весла.

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

НС>Это архитекта, который плодит решения в которых сухогрузы кода, который перекладывает из пустого в порожнее и ничего полезного не делает надо из пушки расстреливать.

Т.е. ты считаешь, что уровень абстракции БД — это всегда никчемная вещь? )

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

_>Ну ок, работа с данными. Но в стиле sql

Что значит "в стиле sql"? Работать с данными в реляционной модели? Это единственный способ получит производительное приложение. Если какой то архитект решил, что модель нужно поменять — стрелять из пушек за профнепригодность.

_>Так вот этот стиль очевидно слишком низкоуровневый, чтобы считать его слоем абстракции БД в приложение.

Непонимаю.

_>Т.е. ты считаешь, что уровень абстракции БД — это всегда никчемная вещь? )

Я считаю что в большинстве случаев абстракция над абстракцией IQueryable — не просто никчемная, а крайне вредная вещь.

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

_>Ну ок, работа с данными. Но в стиле sql (причём этот стиль сохраняется не только при работе с БД, но и с коллекциями). Так вот этот стиль очевидно слишком низкоуровневый, чтобы считать его слоем абстракции БД в приложение.

SQL и Linq — это как раз очень высокий уровень декларативного программирования. SQL вообще обогнал свое время на 30 лет.

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

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

G>>Ты пытаешься с умным видом рассказывать то, что было актуально 10-15 лет назад. Тогда все подряд "пели" про абстрагирование от базы, замену на "свои форматы файлов" итп. Правда термина nosql тогда не было.
G>>Но практика показала обратное. 99% корпоративного софта разрабатывается под конкретную СУБД (иногда с точностью до версии), абстрагирование роняет быстродействие и важно в приложении делать оптимальные запросы. Тот же EF создавался с идеей как ты описываешь, а теперь из него выкидывают все "лишнее", оставляя только генератор запросов и простенький мапинг.
G>>Хотя до сих пор есть упоротые, которые считают что ты всеподряд надо абстрагировать и жирные ORM рулят. Но на практике у них тонны говнокода, все тормозит и логика в хранимках.

_>Ну возможно что во внутрикорпоративном софте и приемлема привязка к одной СУБД.
Я тебе больше скажу. Зачастую привязка желательна. Так как это снижает общие затраты заказчика, повышает быстродействие и надежность.

_>Там собственно и "говнокодить" намного проще, т.к. вообще нет конкуренции (между продукцией).
А это тут при чем? И как связано с базами? Говнокодинг совершенно независим от того сколько баз поддерживается.

_>Однако в других областях ситуация совсем другая. В том же веб'е требование работы с произвольной БД является стандартом де факто для любых движков.
А при чем тут движки, если мы говорим о разработке приложений? Пользователю вообще пофиг что там в бекэнде вордпресса. Не пофиг именно программистам. Если им надо обеспечить хостинг на 100500 платформах и производительность некритична, то имеет смысл заморачиваться на несколько баз, но в большинстве случаев ровно наоборот. Платформа известна заранее, а приложение надо сделать быстрым и надежным.

_>Что касается быстродействия, то я уже написал, что это зависит от языка. Хотя сейчас абстрагирования работы с БД принято делать даже на php. Но там от этого могут быть небольшие потери в производительности (хотя поменьше, чем у linq). А вот в некоторых языках (типа того же C++) даже пара лишних уровней абстракции вообще не поменяет итоговый бинарный код. Или в этом есть сомнения?
Ты о каких "потерях" пишешь? Среднее время обработки запроса процессором по отношению к общему времени — не боле 5%, какая разница что там C#\linq или PHP, важно какие запросы генерируются, а они как раз сильно лучше в случае linq.

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

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


G>>Так ты определись, какая фича хорошая автоматический кеш или выборочный? С точки зрения утилизации памяти и влияния на overall performance это совершенно разные фичи.

_>Естественно выборочный, потому как он позволяет разработчику добиться максимальной эффективности. К сожалению в данный момент эта возможность только в одной БД есть, так что её использование неприемлемо в нормальных проектах. А вот использование обычного кэша вполне приемлемо, т.к. он сейчас имеется почти во всех популярных БД.
То есть пришли к тому же выводу — фактически никто не поддерживает "хорошее" кеширование. Да и его "хорошесть" крайне сомнительна.

_>>>Ну да, а кэш в приложение умеет работать не расходуя оперативную память. Видимо тут какая-то магия. )))
G>>Кеш приложния легко масштабировать, поставить несколько серверов, подключить redis. С базой так не выйдет.

_>Ага... А синхронизация кэша между серверами не будет ничего стоить. Ну да, ну да. ))) Эта проблема даже на суперкомпьютерах стоит во весь рост (с их мегаскоростью между модулями), а ты хочешь на обычных серверах такое сделать и при этом ещё рассчитывать на какую-то производительность. )))
Я делал такое, производительность возрастала в разы. Без всяких извращений на C++. Распределенные кеши имеют такой простой API, что синхронизировать их между серверами почти ничего не стоит.

G>>Я пример не усложнял, я сразу написал, что в select может быть что угодно, и джоин, и подзапрос итд. И сразу писал что разные части в разных модулях. Перечитай внимательнее.
G>>Это ты попытался свести пример к более простому случаю, что и есть слив. Я лишь разъяснил тебе несколько раз, что возможности того, что ты продемонстрировал сильно ниже возможностей linq.

_>Что ты там написал потом в тексте не имеет никакого значения. Пример задаётся конкретным кодом, а не словами. И по коду всё было выполнено. В общем, если ты хочешь попытаться ещё разок, то давай конкретный код. Если же нет, то всем будет очевидно, что ты сдался.
Ты просто не понял код или сделал вид, что не понял. Я тебе пытался объяснить, но ты продолжал делать вид. Я сомневаюсь, что ты настолько не в теме как работает linq, значит просто пытался сузить задачу до удобной тебе. Увы, показанное тобой "решение" крайне далеко от того, что реально делается с помощью linq.


_>>>Да, отлично компилируется. Могу даже показать какой sql он генерирует (там в примере используется некая MockDB, которая просто печатает в консоль sql).
G>>Выложи куданибудь собираемый пример.

_>>>И зачем тут LastName=""? ) И какой sql из этого сгенерируется? )
G>>

G>>select p1.FirstName, '' as LastName
G>>

G>>На клиенте гораздо удобнее когда схема датасета не меняется.

_>Дааа? ))) А как же ты тогда столько тут распинался в полезности проекций? )
А с чего ты решил, что проекция стала бесполезна? Ты не знаешь как работает SQL или у тебя другие причины?

_>Кстати, а как насчёт накладных расходов на перекидывание никчемных данных между БД и приложением? ) Особенно если в результате запроса будет получаться много строк?
Много это сколько? Какой смысл одним запросом тянуть больше строк, чем пользователю выведется на экран (порядка 100 для реальной системы). Передача пустой строки будет стоит практически ничего.
А основные затраты приходятся на чтение с диска, его больше не станет.

G>>Кстати что у sqlcpp11 с выражениями в запросах?
_>См. всё тот же пример. )))

_>Использование индексов конечно же снижает зависимость от размера БД, но это опять же не в пользу linq, т.к. при быстрых запросах накладных расходы как раз становятся более ощутимы.
Для начала надо сгенерировать запрос, который эффективно использует индексы и не снижает поддерживаемость приложения. Как это сделать без linq мы пока не увидели.


_>А в случае попадания в кэш вообще не будет разницы сколько там джоинов — будет одинаковое время выдачи результата. Более того, в этом случае оно всегда будет настолько маленьким, что накладные расходы от linq будут не просто заметны, а убийственны.
Выше мы выяснили что по факту кеша в базе таки нет.

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

НС>Что значит "в стиле sql"? Работать с данными в реляционной модели? Это единственный способ получит производительное приложение. Если какой то архитект решил, что модель нужно поменять — стрелять из пушек за профнепригодность.

Мда?) Ну и как в этой единственной модели получают "производительное" хранение например деревьев? )

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

Хороший слой абстракции БД будет работать в терминах приложения, а не sql таблиц. Я тут уже приводил пример. Если у нас есть такой уровень, то в нём будет грубо говоря функция вида dbAddUser(...). А без такого уровня будет несколько строк с INSERT в разные таблицы, которые надо будет копипастить по приложению.

_>>Т.е. ты считаешь, что уровень абстракции БД — это всегда никчемная вещь? )
НС>Я считаю что в большинстве случаев абстракция над абстракцией IQueryable — не просто никчемная, а крайне вредная вещь.

Чем это оно может быть вредным в языке с нормальной оптимизацией? ) Это как раз IQueryable (как впрочем и остальные порождения linq) вредная вещь из-за своей врождённой тормознутости.

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

С>SQL и Linq — это как раз очень высокий уровень декларативного программирования. SQL вообще обогнал свое время на 30 лет.

Для работы с массивами очень не плохой уровень, да. Но и только. Даже реализация других типов данных уже становится проблематична. А уж об использование в роли внутреннего API приложения вообще нечего говорить, т.к. не реализована возможность добавления специфики приложения. Это про SQL была речь. А конкретная реализация по имени linq вообще ужасна своей тормознутостью. Недаром во всех ответственных местах её заменяют на банальный совсем низкоуровневый for.

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

_>А конкретная реализация по имени linq вообще ужасна своей тормознутостью. Недаром во всех ответственных местах её заменяют на банальный совсем низкоуровневый for.

Что-то тебя уж совсем куда-то не туда понесло.

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

_>>Там собственно и "говнокодить" намного проще, т.к. вообще нет конкуренции (между продукцией).
G>А это тут при чем? И как связано с базами? Говнокодинг совершенно независим от того сколько баз поддерживается.

Говнокодинг тут привязан не к БД, а внутрикорпоративному софту. Т.к. там достаточно добиться того, чтобы приложение кое-как шевелилось (соответствовало ТЗ), и можно скидывать с рук. А в мире нормального софта этого мягко говоря недостаточно, т.к. полно конкурентов и "просто работает" у всех. Тут надо ещё добавлять фичи (в том числе количество поддерживаемых СУБД) и поднимать качество (избавляться от говнокода).

G>А при чем тут движки, если мы говорим о разработке приложений? Пользователю вообще пофиг что там в бекэнде вордпресса. Не пофиг именно программистам. Если им надо обеспечить хостинг на 100500 платформах и производительность некритична, то имеет смысл заморачиваться на несколько баз, но в большинстве случаев ровно наоборот. Платформа известна заранее, а приложение надо сделать быстрым и надежным.

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

G>Ты о каких "потерях" пишешь? Среднее время обработки запроса процессором по отношению к общему времени — не боле 5%, какая разница что там C#\linq или PHP, важно какие запросы генерируются, а они как раз сильно лучше в случае linq.

Ну вообще то это всё не совсем так, но пускай даже прямо так и есть. Тогда тем более непонятно почему ты против добавления слоя абстракции БД (у нас же именно об этом шёл разговор!) — ведь судя по твоим словам процессор то всё равно простаивает всё время, так что можно без проблем добавить ещё хоть десяток слоёв. )))

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

G>То есть пришли к тому же выводу — фактически никто не поддерживает "хорошее" кеширование. Да и его "хорошесть" крайне сомнительна.

Ничего, обычное тупое тоже достаточно эффективно и есть практические во всех БД. )

G>Я делал такое, производительность возрастала в разы. Без всяких извращений на C++. Распределенные кеши имеют такой простой API, что синхронизировать их между серверами почти ничего не стоит.

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

G>Ты просто не понял код или сделал вид, что не понял. Я тебе пытался объяснить, но ты продолжал делать вид. Я сомневаюсь, что ты настолько не в теме как работает linq, значит просто пытался сузить задачу до удобной тебе. Увы, показанное тобой "решение" крайне далеко от того, что реально делается с помощью linq.

Я так понял, что примера кода (который надо повторить на sqlcpp11 и потом сравнить производительность) не будет? )

G>>>На клиенте гораздо удобнее когда схема датасета не меняется.
_>>Дааа? ))) А как же ты тогда столько тут распинался в полезности проекций? )
G>А с чего ты решил, что проекция стала бесполезна? Ты не знаешь как работает SQL или у тебя другие причины?

Я не очень понял как коррелируют твои слова о пользе проекции (причём динамической) с твоим же словами о том, что лучше, когда датасет не меняется.

G>Для начала надо сгенерировать запрос, который эффективно использует индексы и не снижает поддерживаемость приложения. Как это сделать без linq мы пока не увидели.

Это учат каждого студента, при изучение собственно sql.

G>Выше мы выяснили что по факту кеша в базе таки нет.

Это только у тебя так. )))

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

IT>Что-то тебя уж совсем куда-то не туда понесло.

Ну да, это уже была речь не про обсуждаемый здесь linq к БД, а про просто linq, который ещё более печален.

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

IT>>Что-то тебя уж совсем куда-то не туда понесло.
_>Ну да, это уже была речь не про обсуждаемый здесь linq к БД, а про просто linq, который ещё более печален.

Ты его сам видел хотя бы один раз вблизи?