Сообщение Re[48]: EntityFramework - тормоз от 23.04.2015 11:08
Изменено 24.04.2015 9:25 Ночной Смотрящий
Здравствуйте, alex_public, Вы писали:
НС>>Всерьез считаю. Про index includes, к примеру, слышал? Так вот, они работают только при ограничении проекции. Я уж не говорю о том, что в таблицах могут быть вполне объемные блобы.
_>Ну мы же говорим не об обобщённом решение, а о специфическом для каждого случая.
И?
_> Если у нас вдруг будет таблица пользователей с объёмными бинарными данными, то значит сделаем другое решение.
Какое?
_> В каждом случае можно подобрать оптимальное.
Какое?
_> Но мне чаще всего попадались случаи, когда удобнее всего забирать пользователя целиком (прямо при проверке id сессии).
Ну вот прям на этом сайте — идем в профиль и видим один набор полей пользователя. Щелкаем по закладкам — получаем другие поля. Смотрим сообщения — там третьи поля. Список сообщений или оценок — там опять отдельный набор.
_>Я думаю вполне понятно, как такой API будет использоваться из прикладного кода.
С Add все понятно? Там и в линке IQueryable скорее всего не будет. Что насчет Select то?
_>>>Как минимум надо понимать всякие там join'ы, подзапросы и т.п.
НС>>Это надо в любом случае понимать, если ты хочешь получить эффективное решение.
_>Конечно, но в случая слоя абстракции достаточно чтобы это понимал только один специалист, а не все, работающие над приложением.
Нет, недостаточно. Потому что на практике прежде всего presentation layer определяет вид запроса, причем на каждой форме/страничке камк правило запросы уникальны. Так что же получается? Выборку практически всех данных делает твой специалист, html рисуют верстальщики, скрипты пишут тоже специальные люди. Так кому твое API тогда предназначено? Ненужной обезъянке, втыкающей в контроллер проброс вызова в твое возжеланное API?
НС>>Не обязательно. Но я вот опять вижу витание в облаках. Тут тебе объясняют что даже смена одной РСУБД на другую — редчайшее явление, а уж замена РСУБД на нереляционное хранилище — это что то из области струнных теорий.
_>Ну вот если кто-то говорит, что "поддержка нескольких РСУБД — это редчайшее явление", то это просто автоматический диагноз, что человек вообще не в курсе веб-разработки.
Ну ну. Много дон веб-разработал то? А то чета гложут меня смутные сомнения.
НС>>Всерьез считаю. Про index includes, к примеру, слышал? Так вот, они работают только при ограничении проекции. Я уж не говорю о том, что в таблицах могут быть вполне объемные блобы.
_>Ну мы же говорим не об обобщённом решение, а о специфическом для каждого случая.
И?
_> Если у нас вдруг будет таблица пользователей с объёмными бинарными данными, то значит сделаем другое решение.
Какое?
_> В каждом случае можно подобрать оптимальное.
Какое?
_> Но мне чаще всего попадались случаи, когда удобнее всего забирать пользователя целиком (прямо при проверке id сессии).
Ну вот прям на этом сайте — идем в профиль и видим один набор полей пользователя. Щелкаем по закладкам — получаем другие поля. Смотрим сообщения — там третьи поля. Список сообщений или оценок — там опять отдельный набор.
_>Я думаю вполне понятно, как такой API будет использоваться из прикладного кода.
С Add все понятно? Там и в линке IQueryable скорее всего не будет. Что насчет Select то?
_>>>Как минимум надо понимать всякие там join'ы, подзапросы и т.п.
НС>>Это надо в любом случае понимать, если ты хочешь получить эффективное решение.
_>Конечно, но в случая слоя абстракции достаточно чтобы это понимал только один специалист, а не все, работающие над приложением.
Нет, недостаточно. Потому что на практике прежде всего presentation layer определяет вид запроса, причем на каждой форме/страничке камк правило запросы уникальны. Так что же получается? Выборку практически всех данных делает твой специалист, html рисуют верстальщики, скрипты пишут тоже специальные люди. Так кому твое API тогда предназначено? Ненужной обезъянке, втыкающей в контроллер проброс вызова в твое возжеланное API?
НС>>Не обязательно. Но я вот опять вижу витание в облаках. Тут тебе объясняют что даже смена одной РСУБД на другую — редчайшее явление, а уж замена РСУБД на нереляционное хранилище — это что то из области струнных теорий.
_>Ну вот если кто-то говорит, что "поддержка нескольких РСУБД — это редчайшее явление", то это просто автоматический диагноз, что человек вообще не в курсе веб-разработки.
Ну ну. Много дон веб-разработал то? А то чета гложут меня смутные сомнения.
Re[48]: EntityFramework - тормоз
Здравствуйте, alex_public, Вы писали:
НС>>Всерьез считаю. Про index includes, к примеру, слышал? Так вот, они работают только при ограничении проекции. Я уж не говорю о том, что в таблицах могут быть вполне объемные блобы.
_>Ну мы же говорим не об обобщённом решение, а о специфическом для каждого случая.
И?
_> Если у нас вдруг будет таблица пользователей с объёмными бинарными данными, то значит сделаем другое решение.
Какое?
_> В каждом случае можно подобрать оптимальное.
Какое?
_> Но мне чаще всего попадались случаи, когда удобнее всего забирать пользователя целиком (прямо при проверке id сессии).
Ну вот прям на этом сайте — идем в профиль и видим один набор полей пользователя. Щелкаем по закладкам — получаем другие поля. Смотрим сообщения — там третьи поля. Список сообщений или оценок — там опять отдельный набор.
_>Я думаю вполне понятно, как такой API будет использоваться из прикладного кода.
С Add все понятно. Там и в линке IQueryable скорее всего не будет. Что насчет Select то?
_>>>Как минимум надо понимать всякие там join'ы, подзапросы и т.п.
НС>>Это надо в любом случае понимать, если ты хочешь получить эффективное решение.
_>Конечно, но в случая слоя абстракции достаточно чтобы это понимал только один специалист, а не все, работающие над приложением.
Нет, недостаточно. Потому что на практике прежде всего presentation layer определяет вид запроса, причем на каждой форме/страничке камк правило запросы уникальны. Так что же получается? Выборку практически всех данных делает твой специалист, html рисуют верстальщики, скрипты пишут тоже специальные люди. Так кому твое API тогда предназначено? Ненужной обезъянке, втыкающей в контроллер проброс вызова в твое возжеланное API?
НС>>Не обязательно. Но я вот опять вижу витание в облаках. Тут тебе объясняют что даже смена одной РСУБД на другую — редчайшее явление, а уж замена РСУБД на нереляционное хранилище — это что то из области струнных теорий.
_>Ну вот если кто-то говорит, что "поддержка нескольких РСУБД — это редчайшее явление", то это просто автоматический диагноз, что человек вообще не в курсе веб-разработки.
Ну ну. Много дон веб-разработал то? А то чета гложут меня смутные сомнения.
НС>>Всерьез считаю. Про index includes, к примеру, слышал? Так вот, они работают только при ограничении проекции. Я уж не говорю о том, что в таблицах могут быть вполне объемные блобы.
_>Ну мы же говорим не об обобщённом решение, а о специфическом для каждого случая.
И?
_> Если у нас вдруг будет таблица пользователей с объёмными бинарными данными, то значит сделаем другое решение.
Какое?
_> В каждом случае можно подобрать оптимальное.
Какое?
_> Но мне чаще всего попадались случаи, когда удобнее всего забирать пользователя целиком (прямо при проверке id сессии).
Ну вот прям на этом сайте — идем в профиль и видим один набор полей пользователя. Щелкаем по закладкам — получаем другие поля. Смотрим сообщения — там третьи поля. Список сообщений или оценок — там опять отдельный набор.
_>Я думаю вполне понятно, как такой API будет использоваться из прикладного кода.
С Add все понятно. Там и в линке IQueryable скорее всего не будет. Что насчет Select то?
_>>>Как минимум надо понимать всякие там join'ы, подзапросы и т.п.
НС>>Это надо в любом случае понимать, если ты хочешь получить эффективное решение.
_>Конечно, но в случая слоя абстракции достаточно чтобы это понимал только один специалист, а не все, работающие над приложением.
Нет, недостаточно. Потому что на практике прежде всего presentation layer определяет вид запроса, причем на каждой форме/страничке камк правило запросы уникальны. Так что же получается? Выборку практически всех данных делает твой специалист, html рисуют верстальщики, скрипты пишут тоже специальные люди. Так кому твое API тогда предназначено? Ненужной обезъянке, втыкающей в контроллер проброс вызова в твое возжеланное API?
НС>>Не обязательно. Но я вот опять вижу витание в облаках. Тут тебе объясняют что даже смена одной РСУБД на другую — редчайшее явление, а уж замена РСУБД на нереляционное хранилище — это что то из области струнных теорий.
_>Ну вот если кто-то говорит, что "поддержка нескольких РСУБД — это редчайшее явление", то это просто автоматический диагноз, что человек вообще не в курсе веб-разработки.
Ну ну. Много дон веб-разработал то? А то чета гложут меня смутные сомнения.