Здравствуйте, Ночной Смотрящий, Вы писали:
НС>С колекциями совсем другой разговор. Там иные особенности. Основная проблема с перформансом связана с конструированием цепочки энумераторов. Если у тебя инициализаций итераторов много, а количество итераций маленькое, то это время становится заметным на общем фоне. В решарпере как раз такой крайний случай — егойная PSI содержит громадное количество узлов, причем почти в каждом таком узле коротенькие списки вложенных узлов, вплоть до индивидуальных лексем. НС>При этом абсолютные расходы на создание этих итераторов мизерные, единицы микросекунд и менее.
О, и снова интересная дискуссия. Прямо тема неожиданно радовать стала. А то в предыдущие дни она скатилась в какое-то не техническое болото из понтов и демагогии.
Ну так если подвести итоги по этому сообщению и по предыдущему, то по сути получается, что ты в общем то согласен со мной, что с графами всё не очень радостно и в случае SQL БД и в случае просто linq.
НС>Почему это? В шарпе есть структуры.
Я в курсе. ))) А что ты подразумевал под выделением памяти? Так будет разница по сравнению с int'ом или нет?
_>>Обоснуй. ) НС>Я вроде как обосновал уже
Ничего подобного.
_>>Только почему-то весь веб именно так и устроен. ))) НС>Это ложное утверждение.
Ну ОК, имелось в виду весь "коробочный" веб, а не самописный. ) Хотя я частенько вижу (сейчас же есть мода выкладывать всё на github, включая исходники сайтов) слой абстракции БД и у самописных сайтов.
НС>Большинство веб-движков написаны не на шарпе и аналогичного линку там нет.
Там вообще почти всегда динамические языки, так что всякие разновидности ORM рисуются влёт.
НС>Удобнее мыслить и так и так. А вот перформанс, если мыслить объектами становится чудовищным.
А если есть возможность реализовать подобное без потери производительности?
НС>Ответь на простой вопрос — у тея проекция содержит только часть полей User. Ты что возвращать будешь — незаполненный до конца User или специальный одноразовый User42? Проблемы того и другого решения оставляю в качестве домашнего задания.
Функция GetUser очевидно возвращает все поля пользователя. Если же нам надо получить отдельный столбец, то для этого естественно другая функция будет. Само собой это всё о статических запросах (которых большинство в обычных приложениях).
НС>Каков критерий правильности архитектуры?
Работа с хранилищем в терминах приложения, а не в терминах устройства хранилища.
M>>Но лучше не хранить Графовые базы данных рулят S>Это новость для меня. А можно ссылку на какой-нибудь dummy guide по какой-нибудь графовой СУБД? S>Не обязательно по рулящей — пусть хотя бы не очень сосёт
M>>Ему про Фому, он про мне про Ерему. _>ОК, я тебя не понял и думал что мы перешли к обсуждению более интересных вещей.
/o\
M>>Я ему по то, что никакой у всех баз данных несовместимый функционал, он мне про «PostgreSQL еще не будущее».
M>>Я про то, что любое приложение почти сразу начнет использовать функционал, предоставляемый конкретной базой данных, потому что движок сможет предоставить лишь общий для всех баз функционал, он мне про «PostgreSQL еще не будущее».
_>Какое приложение, какой движок? )
Любое приложение, сложнее указанного тобой phpbb. Он, кстати, работает так себе, потому что там, где можно сделать оптимизированные запросы к базе, он полагается на общий функционал и хаки.
_>Ну так этот общий функционал более чем достаточен для большинства целей. Здесь естественно подразумевается именно функционал, а не синтаксис для него (который может быть разный в разных СУБД).
Нет такого «движка» с «легкой абстракцией», который способен предоставить этот функционал на проивзольные запросы, которые могут взбрести в голову разработчикам.
Здравствуйте, Sinclair, Вы писали:
_>>Приемлемым является подход, позволяющий получить все элементы некого поддерева в один запрос к БД. S>Как вы ловко перешли от производительности (которая определяется количеством чтений с диска) к "получению одним запросом".
Вообще то я именно об этом (одном запросе) и писал изначально, так что это ты пытался перевести тему. Показать ссылку/цитату в предыдущих сообщениях? )
_>>В принципе вариант с текстовыми путями и запросами вида like '/path/%' это позволяет, но я думаю не стоит объяснять в чём заключается кривизна данного полухака. Вo многих nosql БД всё получается в один запрос без всяких хаков, так сказать by design. Ну и насколько я слышал (сам не пользовался) в некоторые реляционные СУБД (например в тот же PostreSQL) добавляли специальные возможности (типы) для более вменяемой реализации подхода с путями. . Но во-первых это уже не SQL, так что точно несовместимо ни с чем. S>И опять facepalm. Перед тем, как фонтанировать невежеством, ознакомьтесь с common table expressions. Это вполне себе ANSI SQL, и он поддерживается во всех основных движках. Если уж хочется поговорить про нестандартные расширения SQL для работы с деревьями, то ознакомьтесь с connect by из Oracle.
Я смотрю ты всё чаще и чаще общаешься не с собеседником, а с голосами в свой голове. Иначе я не могу объяснить какое отношение CTE может иметь к "специальным типам для более вменяемой реализации подхода с путями".
S>Замечательно. Вы поверхностно изучили один способ представления иерархических данных в SQL, и позволяете себе делать утверждения космического масштаба.
Я правильно понимаю, что ты хочешь сказать, что у реляционных СУБД всё великолепно в работе с графами? )
S>NoSQL решения, на которые вы ссылаетесь, ложатся навзничь, стоит отойти от единственного типа запросов и/или выйти в размере хранимых данных за пределы RAM. S>А SQL продолжит работать и отдавать данные с приемлемой производительностью.
Оу, вообще интересно стало. И что же именно ломается у nosql БД при выходе за пределы RAM? )
Здравствуйте, Mamut, Вы писали:
M>Любое приложение, сложнее указанного тобой phpbb. Он, кстати, работает так себе, потому что там, где можно сделать оптимизированные запросы к базе, он полагается на общий функционал и хаки.
Ты так пишешь, как будто бы я привёл какое-то исключение. В то время как подобный расклад является как раз нормой в мире веб-движков.)
M>Давай на примерах: M>- windowing functions M>- hierarcical queries M>- generate_sequence
M>Нет такого «движка» с «легкой абстракцией», который способен предоставить этот функционал на проивзольные запросы, которые могут взбрести в голову разработчикам.
Не понял, ты называешь движком некий вариант ORM что ли? ))) Ну так я вообще то как раз на протяжение всей этой темы и пишу, что оптимального обобщённого решения не существует. А вот для каждой конкретной задачи и БД (в смысле таблиц, а не СУБД) это легко делается. И в большинстве веб-движков (ну т.е. по сути приложений в твоей формулировке) как раз и используется слой абстракции БД, реализующий это. Причём делая несколько реализаций (каждая под особенности конкретной СУБД) этого интерфейса мы автоматически получаем поддержку набора разных СУБД.
Здравствуйте, alex_public, Вы писали:
S>>NoSQL решения, на которые вы ссылаетесь, ложатся навзничь, стоит отойти от единственного типа запросов и/или выйти в размере хранимых данных за пределы RAM. S>>А SQL продолжит работать и отдавать данные с приемлемой производительностью.
_>Оу, вообще интересно стало. И что же именно ломается у nosql БД при выходе за пределы RAM? )
Да все у них ломается.
Повторюсь про Монгу — три с половиной панка решили за два года написать то, что превзойдет решения, разрабатываемые с конца 80х не самыми глупыми людьми. Если надо хранить документы Json — в постгресе это есть, и функциональные индексы по этим документам тоже возможны. Я сейчас с ходу не найду, был документ на slideshare, где меряли производительность постгреса и монги на одинаковой задаче хранения документов. Монга мало того, что проиграла по скорости, у нее еще и memory footprint заметно выше оказался.
За реляционками стоит математика и десятилетия исследований, опыта разработчиков и база уже написанного кода. За NoSQL — желание сделать подгружаемую ленту, "как в твиттере", больше там ничего нет. Еще "мы хотим хранить данные без структуры, потому что сегодня мы пишем приложение для продажи какутсов, а когда инвестор не повелся — быстренько его переделаем под продажу роз, а что — и у тех, и у тех есть колючки". NoSQL в вебе — это социальное явление, для перепродажи говностартапов, которые годятся только для перепродажи, использовать и монетизировать их нельзя.
_>Ты так пишешь, как будто бы я привёл какое-то исключение. В то время как подобный расклад является как раз нормой в мире веб-движков.)
Ага. Ты еще наугад применяешь слово «веб-движок».
M>>Давай на примерах: M>>- windowing functions M>>- hierarcical queries M>>- generate_sequence
M>>Нет такого «движка» с «легкой абстракцией», который способен предоставить этот функционал на проивзольные запросы, которые могут взбрести в голову разработчикам.
_>Не понял, ты называешь движком некий вариант ORM что ли? )))
Я не знаю, что ты называешь «движком» и «легким слоем абстракции», так что эти вопросы к тебе.
_>Ну так я вообще то как раз на протяжение всей этой темы и пишу, что оптимального обобщённого решения не существует.
вызовет привязку к конкретной БД как раз только в случае отсутствия слоя абстракции БД. А в нормальных местах работа идёт именно через него + имеем набор реализаций этого слоя под каждую конкретную БД
Внезапно мифический слой абстракции превратился в «я на протяжение темы говорю, что обобщенного решения не сущесвтует», ага
_>А вот для каждой конкретной задачи и БД (в смысле таблиц, а не СУБД) это легко делается. И в большинстве веб-движков (ну т.е. по сути приложений в твоей формулировке) как раз и используется слой абстракции БД, реализующий это. Причём делая несколько реализаций (каждая под особенности конкретной СУБД) этого интерфейса мы автоматически получаем поддержку набора разных СУБД.
Вот мне интересно. Ты упрекаешь меня в том, что я типа невнимательно читаю, а сам продолжаешь игнорировать все, что я пишу, и игнорировать любые мои объяснения и вопросы
Итак. Любые мифические «движки», которые так охрененно все абстрагируют, делают ровно две вещи:
— реализуют только общий для поддерживаемых баз данных функционал
— реализуют некоторое количество неоптимальных хаков для эмуляции некоторых вещей, которые есть в одной базе, но нет в другой.
В итоге все эти мегакрутые phpbb вместо того, чтобы делать один-три запроса к базе на страницу, делают по нескольку десятков.
В итоге в мегасупер мифических системах, работающих со всеми базами, появляются неисправляемые детские баги, произрастающие именно из-за того, что поддерживается только общая функциональность + хаки. (Я лично видел «движок», который, например, эмулировал транзакции для MySQL).
В итоге любое приложение, которому важна хоть какая-нибудь производительность, момнетально скатывается в заточенные под конкретную базу данных запросы, и никакого «ах-ах-ах тонкий слой абстракции, работающий со всем базами» в них не существует.
Ты же продолжаешь активно игнорировать те факты из реальности, о которых я говорю: три топовые базы данных. Oracle, MySQL, MSSQL.
— В MySQL нет windowing functions и hierarchical queries. Да и транзакции там через жопу. Плюс еще до недавнего времени запрос должен был расставлять индексированные поля в начале запроса, иначе можно было получить full table scan на все таблицы в запросе на ровном месте
— В Oracle hierarchical queries еще до недавнего времени реализовались через CONNECT BY и никакой «тонкий слой абстракции» не переписал бы хоть сколько-нибудь сложный запрос под CTE для MSSQL
— это мы еще не говорим про иногда несовместимые типы данных в базах (а иногда совместимые, но с разной семантикой и т.п.)
— это мы еще не говорим про то, что часто запросы надо оптимизировать под конкретные оптимизаторы конкретных баз (что никакой «тонкий слой абстракции» не сделает никогда)
— это еще не добавляя остальные базы из первой десятки популярных, ага.
Но да, но да. «Я думал мы поговорим про что-то интересное», «PostgreSQL еще не будущее» и «читай внимательно».
Здравствуйте, alex_public, Вы писали:
_>О, и снова интересная дискуссия. Прямо тема неожиданно радовать стала. А то в предыдущие дни она скатилась в какое-то не техническое болото из понтов и демагогии.
Ты просто научись отделять одну тему от другой. Здесь разговор шел про работу с БД, поэтому твои пассажи на тему коллекций вызывали, мягко говоря, недоумение.
_>Ну так если подвести итоги по этому сообщению и по предыдущему, то по сути получается, что ты в общем то согласен со мной, что с графами всё не очень радостно и в случае SQL БД и в случае просто linq.
Не надо за меня додумывать. У линка, как и у любой технологии, есть свои особенности. И с графами все очень зависит от этих графов. Конкретно в случае БД есть много разных способов эти графы представлять. Например для иерархии есть штук 10 вариантов.
И проблема с графами вовсе не у линка, а у самих РСУБД. Линк как раз с графами спокойно работает, см. тот же XLinq.
НС>>Почему это? В шарпе есть структуры. _>Я в курсе. ))) А что ты подразумевал под выделением памяти? Так будет разница по сравнению с int'ом или нет?
Классы в шарпе выделяются в куче отдельно, структуры (и инт как частный случай) — по месту.
_>>>Обоснуй. ) НС>>Я вроде как обосновал уже _>Ничего подобного.
Другого обоснования у меня нет.
_>>>Только почему-то весь веб именно так и устроен. ))) НС>>Это ложное утверждение. _>Ну ОК, имелось в виду весь "коробочный" веб, а не самописный.
Это тоже ложное утверждение.
НС>>Большинство веб-движков написаны не на шарпе и аналогичного линку там нет. _>Там вообще почти всегда динамические языки, так что всякие разновидности ORM рисуются влёт.
Динамика это совсем не то, хоть и выглядеть в первом приближении может похоже. Там, к примеру, нет проблемы с нарушением инвариантов, потому что это нарущение в динамике возможно даже для метаданных и подобная забота будет сродни сбиванию соринок с сапог посреди размокшего поля.
НС>>Удобнее мыслить и так и так. А вот перформанс, если мыслить объектами становится чудовищным. _>А если есть возможность реализовать подобное без потери производительности?
Нет такой возможности. Не умеет РСУБД хранить объектный граф эффективно.
НС>>Ответь на простой вопрос — у тея проекция содержит только часть полей User. Ты что возвращать будешь — незаполненный до конца User или специальный одноразовый User42? Проблемы того и другого решения оставляю в качестве домашнего задания. _>Функция GetUser очевидно возвращает все поля пользователя.
Ну и все, можно забыть про перформанс тогда.
_> Если же нам надо получить отдельный столбец, то для этого естественно другая функция будет.
Возвращать она какой тип будет? А если нужно отдельные 5 столбцов?
НС>>Каков критерий правильности архитектуры? _>Работа с хранилищем в терминах приложения, а не в терминах устройства хранилища.
Здравствуйте, alex_public, Вы писали:
_>У тебя часто встречаются sql запросы на несколько экранов кода? )
Несколько экранов и не нужно. Плотность логики в запросах сильно выше, чем в императивном коде. Так что и полэкрана хватит чтобы без декомпозиции затосковать.
G>>Ты написал sql с помощью склейки строк и пропустил там sql-инъекцию. Ты сам прекрасно продемострировал, что linq сработал лучше человека. Почему продолжаешь спорить? _>Кстати не факт. Если указанные в том запросе строки приходили не от пользователя
Здравствуйте, Sinclair, Вы писали:
НС>>Все именно так просто. Я проверял. Строго-типизированный вариант прекрасно работает. Нерешенных неприятностей на момент, когда я покинул проект не было. S>Прикольно.
Не то слово. Зато какой кайф, когда все типы можно вытащить просто из текста запроса, не лазя в БД. А то я такие перлы встречал. Иногда даже видел как делают select top 0 просто чтобы достать результирующий тип кортежа.
НС>>Это все сравнительно легко решаемо. В конце концов cast никто не отменял. Ну и на практике подобное встречается совсем нечасто. S>Может быть я преувеличенно паранойю. Каст он, конечно, каст, но как раз не хочется постоянно кастить.
Я ж говорю — решается. В ряде случаев сравнительно безопасно сделать неявный кастинг, к примеру. Но в целом да — для механики неявного преобразования типов неплохо бы отдельный RnD сделать. Однако это, в любом случае, совершенно за рамками классического SQL.
Здравствуйте, alex_public, Вы писали:
_>А вот если мы например глянем на какой-то современный форумный движок (ну скажем на nodebb), то увидим, что там и функциональности поинтереснее rsdn.ru
Как очередной *bb научится иерархические форумы, так сразу и приходите. А ленту показывать много ума не нужно.
_> и отзывчивость повыше.
Отзывчивость rsdn.ru в производительность сервера сейчас почти нигде не упирается.
S>>Заметьте, вы противопоставляете свои теоретические соображения практическому опыту людей, которые работали с высоконагруженными приложениями. _>Хыхы, это rsdn то являются сложным и высоконагруженными приложением? ) Да подобные нагрузки при аналогичной функциональности держат на простеньких серверах древние php движки с mysql базами.
Пенисометрия это всегда весело, но надо понимать что данные мониторинга rsdn.ru показывают, что в скорость сервера сейчас почти нигде сайт не упирается.
Здравствуйте, Sinclair, Вы писали:
S>И опять facepalm. Перед тем, как фонтанировать невежеством, ознакомьтесь с common table expressions. Это вполне себе ANSI SQL
Начиная с SQL'99, если быть точным. В оригинальном SQL'92 CTE еще не было. А вообще, ИМХО, за CTE надо отстреливать яйца. Такую угребищную конструкцию надо было постараться придумать.
Но самый пик маразма это, безусловно, способ задания пейджинга все в том же, емнип, SQL'99. Это который SELECT OVER. Сторонники, сука, чистоты концепции. Слава богу в последнем стандарте сделали почти как надо (FETCH NEXT ...). А совсем как надо — в проприетарном диалекте PGSQL.
Здравствуйте, alex_public, Вы писали:
_>Ты читай внимательнее. Я же ясно написал "пока до этого ещё далеко". Просто направление развития у PostgreSQL очень интересное стало на мой взгляд. Они движутся в сторону добавления к себе всех возможностей nosql баз
И не только постгри. mssql в следующем релизе тоже что то похожее обещает. Только что тебя удивляет здесь — непонятно. Появился спрос — производители реагируют.
Здравствуйте, alex_public, Вы писали:
_>А запросы кэшируются всегда целиком? Ну т.е. если скажем в запросе поменяется значение id в "where id=xxx", то запрос будет заново парситься и компилироваться или нет?
Нет. Такие вещи заменяются на параметры, запрос остается тем же.
_>Пока мой комментарий из этих цифр: для быстрых sql запросов смысл снижать накладные расходы за счёт linq всё же есть.
С быстрыми sql запросами обычно и проблем с перфомансом нет.
Здравствуйте, Sinclair, Вы писали:
S>>>В рамках одного запроса он непревзойдён — встроенную в него механику вывода типов десятилетиями не удавалось догнать в промышленных языках программирования. S>>>(Вот я, к примеру, до сих пор не вполне понимаю, каким образом эту проблему решает sqlpp). EP>>Что конкретно? На основе проекции создать соответствующий тип данных? S>Да. В С# чтобы решить эту "маленькую частную проблемку, известную под названием Великой проблемы Ауэрса", прикрутили Анонимные Типы и их вывод по использованию в query comprehensions. S>Как у нас с этим обстоят дела в С++?
#define FIELD(type, name) \
template<typename T> \
struct column_ ## name \
{ \
struct field \
{ \
T name; \
}; \
}; \
column_ ## name <type> name \
/**/template<typename ...Columns>
struct row : Columns::field...
{};
template<typename ...Columns>
auto select(Columns...)
{
return row<Columns...>{};
}
/********************************************/struct
{
FIELD(int, id);
FIELD(double, value);
FIELD(bool, flag);
} table;
int main()
{
auto x = select(table.id, table.value);
x.id = 11;
x.value = 0.11;
x.flag = true;
auto y = select(table.id, table.flag);
y.id = 11;
y.value = 0.11;
y.flag = true;
}
main.cpp:37:7: error: no member named 'flag' in 'row<column_id<int>, column_value<double> >'
x.flag = true;
~ ^
main.cpp:41:7: error: no member named 'value' in 'row<column_id<int>, column_flag<bool> >'
y.value = 0.11;
~ ^
Макросы нужны только для первоначального объявления таблиц с полями, так как пока ещё нет compile-time reflection.
Графовые базы данных рулят 
Всё же ты не в реальном мире живёшь. ) Одно IT подразделение Сбербанка больше 3000 человек
