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

_>Что подразумевается под иерархическим форумом? ) Если речь про древовидное отображение ветки дискуссии, то это в очень многих имеется (причём в виде переключателя).

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

_>Хм, а во что тогда упирается?

По разному. Иногда в клиентские скрипты, иногда в канал. Открой в браузере таймлайн да посмотри где задержка.

_> Потому как у меня периодически при отправке сообщения на форум сайт подвисает, держится так какое-то время и потом выдаёт какую-то странную ошибку.

А у меня не подвисает и ошибок не выдает. И при отправке, кстати, работает вовсе и не линк, а банальная хранимка.

Здравствуйте, Нахлобуч, Вы писали:

Н>>>Так я что-то не понял, по твоему эти твои ссылки подтверждают моё утверждение, опровергают его или что? ) Как они вообще к нему относятся? )
Н>Первое -- это о том как "работает" "шардинг из коробки". Второе -- это о том как "работает" MongoDB вообще.

Ну и как это воспринимать в контексте моей фразы о том, что "шардинг из коробки" — это главное преимущество подобных БД? Как подтверждение того, что да, действительно работает из коробки? )

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

_>>Однако если такие запросы наиболее популярны, то оптимизация подобных накладных расходов может позволить держать на том же сервере гораздо большую нагрузку.
НС>CompiledQuery эту проблему решает.

Возможно) Кстати, а как это выглядит в коде?

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

_>>Ну так я и для mail.ru брал общую численность сотрудников, так что всё честно.
НС>Честно будет, если ты докажешь что процент it pro и там и там одинаковый.

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

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

_>>Кстати, а про ORM я тут уже как раз писал, что это попытка обобщения подобного слоя абстракции.
НС>Гениально! Теперь осталось понять, что если попытка эта достаточно качественная, то пытаться поверх сделать еще одно обобщение — вредно.

А кто тут говорил про "поверх"? )

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

_>>В произвольном случае конечно. Однако для конкретной задачи (особенно если в ней нет произвольных деревьев) это становится более реально.
НС>Ну а для конкретного случая и у линка проблем нет.

Кстати, давно хотел спросить. А если нам понадобится обеспечивать сохранения в БД состояния (естественно не со всеми полями — всякие там дескрипторы и т.п. не нужны) некого уже существующего (скажем наследника тяжёлого библиотечного класса) сложного класса, то это вызовет какие-то сложности или же тоже без проблем?

_>>С чего бы это? )
НС>С того что лишние поля будут выбираться без надобности.

Ты всерьёз считаешь, что если запросить одну строку из БД целиком, то это будет ощутимо медленнее, чем запросить эту же строку без пары столбцов? )

_>> Без уточнения конкретной задачи это всё бессмысленный разговор.
НС>Тут все вполне конкретно. В реальных задачах набор полей в основном уникален. Рисовать на каждый случай новый тип — геморой, возвращать недозаполненный тип или безликий кортеж — отличный способ прострелить себе ногу, возвращать все поля — удар по перформансу.

В реальных задачах чаще всего надо или всю строку или одно поле из неё. ) И даже если в каком-то редком случае понадобится именно некий набор полей, то это тоже без проблем и удобно задаётся в API для случая статических запросов.

НС>На цель, извини, не тянет. Цель любого продуктва — удовлетворять требованиям. Заказчик такого требования не выставляет. Так что это уже твои экзерсисы. Поэтому попробуй их обосновать, а не выдавай за аксиому.

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

_>>- родное (через свои типы) API к хранилищу
НС>Что такое "родное API" и чем оно лучше неродного?

Я же указал в скобках — работает через те же типы данных, что и само приложение. И лучше оно удобством.

_>>- программистам в остальной части приложения не надо знать тонкости работы хранилища — этим может заниматься один спец. по нему
НС>IQueryable обеспечивает тоже самое.

Как минимум надо понимать всякие там join'ы, подзапросы и т.п. Не говоря уже о том, что для некоторых БД некоторые типы запросов могут оказываться неэффективными.

_>>- при необходимости можно легко сменить тип хранилища.
НС>IQueryable обеспечивает тоже самое.

Только в рамках реляционных СУБД. Или быть может linq2db может помочь сохранить данные в MongoDB? )

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

AVK>По разному. Иногда в клиентские скрипты, иногда в канал. Открой в браузере таймлайн да посмотри где задержка.

Сам форум у меня обычно не тормозит. )

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

_>> Потому как у меня периодически при отправке сообщения на форум сайт подвисает, держится так какое-то время и потом выдаёт какую-то странную ошибку.
AVK>А у меня не подвисает и ошибок не выдает.

Это "серьёзный" аргумент. )))

AVK>И при отправке, кстати, работает вовсе и не линк, а банальная хранимка.

А что так? )

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

AVK>>По разному. Иногда в клиентские скрипты, иногда в канал. Открой в браузере таймлайн да посмотри где задержка.
_>Сам форум у меня обычно не тормозит. )

Я именно про сам форум говорил (+ ряд самых часто используемых страниц). Непереписанных старых кусков на сайте еще море.

_>Да, кстати, пользуюсь случаем могу сообщить, что подписку (уведомления по почте) на новые сообщение в разделе вы так и не починили — ко мне ничего не приходит.

Тут я ничем не могу помочь, от нас все уходит.

_>>> Потому как у меня периодически при отправке сообщения на форум сайт подвисает, держится так какое-то время и потом выдаёт какую-то странную ошибку.
AVK>>А у меня не подвисает и ошибок не выдает.
_>Это "серьёзный" аргумент. )))

Это намек на то, что тебе, наверное, не хотелось бы получать багрепорты типа твоего.

AVK>>И при отправке, кстати, работает вовсе и не линк, а банальная хранимка.
_>А что так? )

Руки не дошли.

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

_>>>Однако если такие запросы наиболее популярны, то оптимизация подобных накладных расходов может позволить держать на том же сервере гораздо большую нагрузку.
НС>>CompiledQuery эту проблему решает.
_>Возможно) Кстати, а как это выглядит в коде?

В случае динамической композиции (в которой "сила" LINQ) мнения расходятся от "Да в принципе можно, никто не мешает нагенерить Expression и прогнать все через compiled query

Автор: Ночной Смотрящий
Дата: 19.04.15

" до "Это просто невозможно

Автор: Ночной Смотрящий
Дата: 19.04.15

"

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

НС>>>>Кто то из них не поддерживает стандарт? Уж SELECT OVER то все должны уметь.
M>>>MySQL вестимо.

НС>>Ты этого уродца с нормальными серверами не ровняй.


M>Еще один нашелся. Какая разница, уродец он или не уродец. Это один из самых популярных в мире движков. Особенно в контексте веб-разработки, о которой тут вещал alex_public.
Сейчас уже модно LocalBD использовать

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

_>Возможно) Кстати, а как это выглядит в коде?

В этом топике пример уже был. Запрос просто оборачивается CompiledQuery и полученный результат многократно используется.

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

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

Не вызовет. Ты этот вопрос, помнится, уже задавал.

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

Всерьез считаю. Про index includes, к примеру, слышал? Так вот, они работают только при ограничении проекции. Я уж не говорю о том, что в таблицах могут быть вполне объемные блобы.

_>В реальных задачах чаще всего надо или всю строку или одно поле из неё.

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

НС>>На цель, извини, не тянет. Цель любого продуктва — удовлетворять требованиям. Заказчик такого требования не выставляет. Так что это уже твои экзерсисы. Поэтому попробуй их обосновать, а не выдавай за аксиому.
_>Согласен, но здесь подразумевалось что это цель для "правильной архитектуры" (которая опять же нафиг не нужна заказчику).

Еще раз. Чтобы отличить правильную архитектуру от неправильной нужен критерий. Критерий этот должен быть осмысленным, приводящим к конкретным бенефитам, а не чьей то голой хотелкой.

_>>>- родное (через свои типы) API к хранилищу
НС>>Что такое "родное API" и чем оно лучше неродного?
_>Я же указал в скобках — работает через те же типы данных, что и само приложение.

Ниче не понял. IQueryable, если что, он на самом деле IQueryable<T> в котором Т вполне себе родной.

_> И лучше оно удобством.

Докажи.

_>>>- программистам в остальной части приложения не надо знать тонкости работы хранилища — этим может заниматься один спец. по нему
НС>>IQueryable обеспечивает тоже самое.
_>Как минимум надо понимать всякие там join'ы, подзапросы и т.п.

Это надо в любом случае понимать, если ты хочешь получить эффективное решение.

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

Например?

_>>>- при необходимости можно легко сменить тип хранилища.
НС>>IQueryable обеспечивает тоже самое.
_>Только в рамках реляционных СУБД.

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

_> Или быть может linq2db может помочь сохранить данные в MongoDB? )

linq2db нет, только IQueryable это не linq2db.

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

_>>Ты всерьёз считаешь, что если запросить одну строку из БД целиком, то это будет ощутимо медленнее, чем запросить эту же строку без пары столбцов? )
НС>Всерьез считаю. Про index includes, к примеру, слышал? Так вот, они работают только при ограничении проекции. Я уж не говорю о том, что в таблицах могут быть вполне объемные блобы.

Вот кстати, а как быть с join'ом в случае связи один ко многим? Если делать один простой запрос, то в результате будет дублирование данных — например те самые объёмные блобы. Какова практика? Или что например делает linq2db?

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

EP>Вот кстати, а как быть с join'ом в случае связи один ко многим? Если делать один простой запрос, то в результате будет дублирование данных — например те самые объёмные блобы. Какова практика? Или что например делает linq2db?

Простой вопрос — без линка ты как сделаешь?

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

EP>>Вот кстати, а как быть с join'ом в случае связи один ко многим? Если делать один простой запрос, то в результате будет дублирование данных — например те самые объёмные блобы. Какова практика? Или что например делает linq2db?
НС>Простой вопрос — без линка ты как сделаешь?

У меня вопрос скорее не про LINQ, а про практику SQL (а потом уже как на неё отображается LINQ).
Если нужно избежать дублирование, то как я понимаю тут три принципиальных варианта:
1. Сделать несколько запросов (тут много вариаций).
2. Сделать один запрос, но в одном из столбцов будет "упакован" список значений.
3. N + 1 запрос.

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

EP>У меня вопрос скорее не про LINQ'е, а про практику SQL

Очень тяжело с вами двоими общаться, какое то мозаичное сознание.

EP>Если нужно избежать дублирование, то как я понимаю тут три принципиальных варианта:
EP>1. Сделать несколько запросов (тут много вариаций).
EP>2. Сделать один запрос, но в одном из столбцов будет "упакован" список значений.
EP>3. N + 1 запрос.

Все верно. linq2db, если оставить на его усмотрение, обычно использует 3 вариант, linq2sql (и, скорее всего, EF) — использует произведение кортежей. Руками — чаще всего первый вариант. К счастью, такое требуется нечасто.

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

_>>>> Потому как у меня периодически при отправке сообщения на форум сайт подвисает, держится так какое-то время и потом выдаёт какую-то странную ошибку.
AVK>>>А у меня не подвисает и ошибок не выдает.
_>>Это "серьёзный" аргумент. )))
AVK>Это намек на то, что тебе, наверное, не хотелось бы получать багрепорты типа твоего.

Только что была такая ошибка при редактировании сообщения: после нажатия на "Отправить", происходит подвисание на несколько секунд, потом выдало:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

во время подвисания другие страницы форума зависают при обновлении по F5, хотя другие сайты работают.

Здравствуйте, Evgeny.Panasyuk, Вы писали:
Ок, я понял. Обстоят чуть хуже, чем никак:

struct
{
    FIELD(int, appleId);
} apples;


struct
{
    FIELD(int, orangeId);
} oranges;

int main()
{
    auto x = select(apples.appleId, oranges.orangeId); // WTF is x???
}

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

EP>Только что была такая ошибка при редактировании сообщения: после нажатия на "Отправить", происходит подвисание на несколько секунд, потом выдало:
EP>

EP>Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Как минимум, это — хранимка, а не linq.
EP>во время подвисания другие страницы форума зависают при обновлении по F5, хотя другие сайты работают.
Это — штатная фича браузера: ограничение количества параллельных коннектов к одному хосту.

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

EP>>У меня вопрос скорее не про LINQ'е, а про практику SQL
НС>Очень тяжело с вами двоими общаться, какое то мозаичное сознание.

Что значит "мозаичное"

EP>>Если нужно избежать дублирование, то как я понимаю тут три принципиальных варианта:
EP>>1. Сделать несколько запросов (тут много вариаций).
EP>>2. Сделать один запрос, но в одном из столбцов будет "упакован" список значений.
EP>>3. N + 1 запрос.
НС>Все верно. linq2db, если оставить на его усмотрение, обычно использует 3 вариант, linq2sql (и, скорее всего, EF) — использует произведение кортежей. Руками — чаще всего первый вариант.

Понятно, спасибо.

НС>К счастью, такое требуется нечасто.

Понимаю что не часто и что дублирование при произведении в большинстве случаев не критично. Но раз тут разговор зашёл про экономию и объёмные блобы — решил спросить.