Здравствуйте, Cyberax, Вы писали:
C>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?
Какой смысл в отображении одного мегабайта данных?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Tom, Вы писали:
G>>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject). Tom>>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
VD>Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так: VD>
VD>X GetById(int id)
VD>{
VD> return (from x in xs where x.id = id select x).Fitst();
VD>}
VD>...
VD>... GetById(GetId())
VD>
VD>если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?
Как правило получать что-то по id как раз нужно не раз в год, а постоянно и из разных мест.
Здравствуйте, IT, Вы писали:
C>>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем? IT>Какой смысл в отображении одного мегабайта данных?
Это совсем не так много, как кажется. Особенно, если туда входят картинки.
Здравствуйте, VladD2, Вы писали:
VD>Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так: VD>
VD>X GetById(int id)
VD>{
VD> return (from x in xs where x.id = id select x).Fitst();
VD>}
VD>...
VD>... GetById(GetId())
VD>
VD>если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?
Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.
Здравствуйте, VladD2, Вы писали:
VD>SOA — это драцкий базворд за которым нет ничего нового. К компонентам (кстати "компонентов", а не "компонента") SOA не имеет никакого отношения. Расшифровывается этот базворд как "архитектура ориентированная на сервисы". Это тоже самое что серверы ориентированные на RPC. Дурацкий базвордов придумать можно миллионы (что и делаеют конторы вроде МС каждый день), но толку от этого не будет, так как ничего принципиально нового от этот не появится. VD>SOA родилась в момент когда в МС полностью отчаялись протащить DCOM в область разработки серверов приложений. Тогда они понял, что общаться с серверами намного проще по средствам RPC (без сохранения состояния между вызовами на сервере). Тогда срочно придумали веб-сервисы, а чтобы все это круто звучало и никто не догадался, что это просто откат к более "примитивной" технологии и признание недееспособности ООП в области организации распределенных вычислений назвали все это SOA. Как и любой базворд это звучит красиво, не понятно. Что еще нужно чтобы завуалировать собственную глупость?
То о чем ты пишешь скорее относится не SOAP, но уж совсем не к SOA.
Первое (SOAP) — описание формата сообщений и не более того.
Второе (SOA) — архитектурный подход к "разрезанию" логики приложений.
Здравствуйте, gandjustas, Вы писали:
A>>Ты не прав. G>В чем? G>У вас проверки RLS не в коде?
Да, они в хранимках.
G>Это сама субд делает? Покажите мне эту субд.
Это SQL Server. Так как проверки прав доступа в конечном итоге сводятся к фильтрации по индексированному полю, мы получаем многократный прирост в производительности, так как многие данные вообще не читаются с диска.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.
Голословное утверждение. Каким образом чтение и последущий отсев данных улучшает безопасность по сравнению с запретом чтения?
C>>Реплики БД — это исключительно кривой хак. KV>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили
Здравствуйте, VladD2, Вы писали:
MC>>Как правило получать что-то по id как раз нужно не раз в год, а постоянно и из разных мест. VD>Дык ты правила придумал. Меняй их.
Влад, создание альтернативной реальности это не метод разработки архитектуры ПО.
Здравствуйте, VladD2, Вы писали:
A>>Да нет, дело не в том что удобнее, а в том что правильнее. VD>Супер. Новое инженерно-научный постулат "правильнее". VD>Можно задать критерии правильности в общем случае?
Влад, если нечего сказать по существу, то лучше вообще не писать, ведь разговаривать про клиентский кеш ты недавно отказался. Искать "the answer to life, the universe and everything" можешь без меня.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации. C>Дело в том, что нужно обеспечивать и контроль данных — чтобы любой пользователь не мог подсмотреть номер кредитки директора.
Забавно, ты сам же и описал задачу в терминах операций BL Уточню, речь о row-level security, упомянутой gandjustas'ом или о чем-то ином?
Кстати, а что ты будет делать с атаками man-in-the-middle?
C>>>Реплики БД — это исключительно кривой хак. KV>>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили C>Скажи, и нравится тебе как работает Лотус?
Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.
A>Голословное утверждение. Каким образом чтение и последущий отсев данных улучшает безопасность по сравнению с запретом чтения?
Зачем читать все, чтобы потом отсеять?
C>>>Реплики БД — это исключительно кривой хак. KV>>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили
A>И как оно работает?
Вполне. И мне страшно подумать, как решались бы вопросы масштабирования и плохих каналов (плохой == < 10Мбит), если бы в лотусе не было этой "особенности". С чем собственно мы и столкнулись в 1С, и из-за чего с нее, в итоге, и свалили.
Здравствуйте, kochetkov.vladimir, Вы писали:
C>>Дело в том, что нужно обеспечивать и контроль данных — чтобы любой пользователь не мог подсмотреть номер кредитки директора. KV>Забавно, ты сам же и описал задачу в терминах операций BL
Ну считай, что в BL есть generic-операция "взять объект".
KV>Уточню, речь о row-level security, упомянутой gandjustas'ом или о чем-то ином?
У меня это object-level security. Естественно, это не отменяет security на операции.
KV>Кстати, а что ты будет делать с атаками man-in-the-middle?
Так как обычно security каналов связи (HTTPS со строгой проверкой сертов). Или ты что-то другое имеешь в виду?
C>>Скажи, и нравится тебе как работает Лотус? KV>Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент
Тем не менее, это подход очень глючный. Для email-серверов он ещё сгодится — нет особых ограничений на время и консистентность синхронизации.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат. G>>Ты наверное не понял что использование DML позволяет вообще не тянуть на клиент никакие данные, материализовываться выборки будут только с целью отображения. C>"Вообще не тянуть на клиент никакие данные" — это смешно.
Эт овполне возможно.
C>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?
И что? Про кеширование я уже написал.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так: VD>>
VD>>X GetById(int id)
VD>>{
VD>> return (from x in xs where x.id = id select x).Fitst();
VD>>}
VD>>...
VD>>... GetById(GetId())
VD>>
VD>>если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?
L>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.
А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update, а не SELECT+Update+ оптимистичная блокировка+identity map+навороченный кеш?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Ты не прав. G>>В чем? G>>У вас проверки RLS не в коде? A>Да, они в хранимках.
От того что часть логики помещена в хранимки она логикой быть не перестает.
Зато теперь понятно почему тебе так не нравятся запросы, используя хранимки для CRUD использование запросов становится неудобным и почти ненужным.
Здравствуйте, gandjustas, Вы писали:
L>>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе. G>А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update,
Например то, что в этой цепочке присутствует пользователь и ему надо-таки что-то показать. Для этого и нужен GetById.
А по поводу того, как организовать запись в БД, я вроде ничего и не писал.
Здравствуйте, Cyberax, Вы писали:
C>>>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем? IT>>Какой смысл в отображении одного мегабайта данных? C>Это совсем не так много, как кажется. Особенно, если туда входят картинки.
Ну так в чём тогда проблема? Объективная реальность
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
C>>>>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем? IT>>>Какой смысл в отображении одного мегабайта данных? C>>Это совсем не так много, как кажется. Особенно, если туда входят картинки. IT>Ну так в чём тогда проблема? Объективная реальность
Хочется чтоб всё быстро работало
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
L>>>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе. G>>А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update,
L>Например то, что в этой цепочке присутствует пользователь и ему надо-таки что-то показать. Для этого и нужен GetById.
Для этого нужен один select.
Вообще если не думать о работе с даннми в терминах GetById, FindByЧтототам, то жить становится гораздо проще.
Если нам не помогут, то мы тоже никого не пощадим.
Религия?
