Здравствуйте, VladD2, Вы писали:
C>>1) Контроль доступа. VD>И что с ним?
Сложно сделать на уровне чистых данных.
C>>2) Время синхронизации — у меня оповещения рассылаются меньше чем за секунду. VD>А почему репликация данных не может работать с той же скоростью? Секунда — это довольно много.
Я не знаю технологий репликации, которые это бы обеспечивали.
C>>3) Простота клиента. У меня это просто приложение, которое пользователь запускает через WebStart. Пользователям не надо думать о файрволах, публичных IP и т.д. VD>Причем тут клиент? У тебя ведь сервер данные кэширует? Мы вообще что обсуждаем? Может я вас не верно понял?
Именно клиент кэширует, которых одновременно может быть сотни штук.
VD>Еще раз я говорю о том, что заниматься сложным кэшированием в сервере приложения неразумно. Если серверы вынуждены работать на разнесенными далеко друг от друга, лучше иметь локальные копии БД для каждого сервера которые будут синхронизироваться между собой. Это самый лучший и бескомпромиссный кэш.
Ага, и начинать ловить проблемы, когда одна из реплик вдруг выйдет из синхронизации.
То что ты предлагаешь — это примерно на уровне старых дельфийских программ.
C>>Представь, что у нас есть две таблицы Person (id, date_created) и PersonalDetails(id, parent_id, name, last_name). Мы делаем запрос "SELECT pers.id, det.name, det.last_name FROM Person pers, PersonalDetails det where pers.id=det.parent_id" и кладём его результаты в кэш. VD>А зачем часто изменяемые данные кэшировать. Такие данные я буду запрашивать каждый раз.
Каждый запрос по WAN — это секунда, грубо говоря. Просто обязан кэшировать.
VD>Реч шла о чем-то что редко изменяется. Например о списке наменклатур. Бывает так, что они обновляются раз в месяц. В таких условиях тянуть описания продуктов из БД смысла нет. Хотя тоже стоит подумать, так как если этот список огромен, а каждый раз нужно вытаскивать всего 1-5 записей, то опять же кэш может оказаться бессмысленными.
Я вот хочу кэшировать и изменяемые данные. Можешь предложить вариант? Или таки признаешь, что ORM имеют существенные преимущества в ряде случаев?
VD>В общем, кэш — это оптимизация. И надо сто раз подумать прежде чем ей заниматься. В отличии от этого реплика БД — это архитектурное решение. Он лишено проблем связанных с кэшировнием. Оно бескомпромиссно.
Реплики БД — это исключительно кривой хак.
C>>Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами. VD>То на что ты намекаешь — это болезнь под названием заменить БД кэшем в сервере приложения.
И что дальше? Почему я должен молиться на БД и считать её недостяжимым идеалом, попытка повторить часть функций которого является величайшей дерзостью?
C>>Предлагай решения. VD>Перестать дублировать работу сервера БД.
Не решение.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Tom, Вы писали:
G>>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject). Tom>>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия? G>Могут, только это будет не DAL.
Чуш какая то. Почему это будет не DAL? Где то есть религиозные огроаничения? Что ты под DAL понимаешь?
G>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
От клиента до сервера БД. ТАк же как и в самих запросах. Так что эти разделения на BL/DAL предлагаю сразу забыть.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Tom, Вы писали:
A>>>QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно. Tom>>Тут соглашусь с Ромой G>С чем соглашиься? С голословным утверждением? G>Может тогда ты ответишь почему это "просто неправильно" ?
Потому что серебрянной пули на практике не бывает.
Если на все задачи по работе с данными у тебя есть один единственно правильный ответ, то что то тут не так.
Если не согласен предлагаю перейти от розового слоника в вакууме перейти на примеры. Обсуждать воздух очень тяжело.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>>>Права доступа на уровне DAL — великая вещь. G>>>>У тебя фильтрация по уровню доступа в DAL? G>>>>Это ужасно. A>>>Это замечательно, потому что в фильтрации нет бизнес-логики. G>> G>>Это и есть бизнес-логика.
A>Какая бизнес-логика в правах доступа NTFS?
Её там нет, также как нету бизнес-логики в правах доступа к объектам СУБД.
Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать).
Здравствуйте, gandjustas, Вы писали:
A>>Какая бизнес-логика в правах доступа NTFS? G>Её там нет, также как нету бизнес-логики в правах доступа к объектам СУБД.
Считай, что строка таблицы — объект СУБД.
G>Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать).
Нет. Раздача конкретных прав доступа это бизнес-логика. А проверка — нет.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Какая бизнес-логика в правах доступа NTFS? G>>Её там нет, также как нету бизнес-логики в правах доступа к объектам СУБД.
A>Считай, что строка таблицы — объект СУБД.
Я могу так считать, а сама СУБД начнат проверять разрешения от этого?
Проверки все равно ложатся на клиентский код независимо от того как я считаю.
G>>Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать). A>Нет. Раздача конкретных прав доступа это бизнес-логика. А проверка — нет.
Запишу этот перл в коллекцию.
Здравствуйте, gandjustas, Вы писали:
A>>Считай, что строка таблицы — объект СУБД. G>Я могу так считать, а сама СУБД начнат проверять разрешения от этого? G>Проверки все равно ложатся на клиентский код независимо от того как я считаю.
Ты не прав.
G>>>Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать). A>>Нет. Раздача конкретных прав доступа это бизнес-логика. А проверка — нет. G>Запишу этот перл в коллекцию.
Здравствуйте, Tom, Вы писали:
Tom>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Tom, Вы писали:
G>>>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject). Tom>>>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия? G>>Могут, только это будет не DAL. Tom>Чуш какая то. Почему это будет не DAL? Где то есть религиозные огроаничения? Что ты под DAL понимаешь?
Уровень абстракции с помощью которого я могу работать с данными в терминах языка программирования, а не SQL.
G>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL. Tom>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
Tom>От клиента до сервера БД. ТАк же как и в самих запросах. Так что эти разделения на BL/DAL предлагаю сразу забыть.
Это видимо от того что у тебя не получилось корректно провести границу.
ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.
Здравствуйте, Cyberax, Вы писали:
C>Реплики БД — это исключительно кривой хак.
Ыыыыыуууыыыйй! Я плякаль! А еще говорят умер юмор на нашей эстраде.
Ладно. Спорить на таком уровне я не готов. Пилите Шура! Пилите! Они золотые. (с)
C>И что дальше? Почему я должен молиться на БД и считать её недостяжимым идеалом, попытка повторить часть функций которого является величайшей дерзостью?
Я даже не знаю. Это же твоя идея. От тебя и ответа ждать.
Если ты не верно сформулировал вопрос и хочешь спросить почему не стоит повторять функции СУБД в своем приложении, то я могу ответить. Потому, что это море очень серьезного кода воспроизвести качественно который ты не сможешь. Будет жалкая пародия, в лучшем случае.
C>>>Предлагай решения. VD>>Перестать дублировать работу сервера БД. C>Не решение.
Пилите Шура... Пилите...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Tom, Вы писали:
A>>>>QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно. Tom>>>Тут соглашусь с Ромой G>>С чем соглашиься? С голословным утверждением? G>>Может тогда ты ответишь почему это "просто неправильно" ?
Tom>Потому что серебрянной пули на практике не бывает. Tom>Если на все задачи по работе с данными у тебя есть один единственно правильный ответ, то что то тут не так. Tom>Если не согласен предлагаю перейти от розового слоника в вакууме перейти на примеры. Обсуждать воздух очень тяжело.
Да, у меня на все есть один ответ — DML. Разве его недостаточно для выполнения любой задачи по работе с данными?
К сожалению современные средства позволяют описывать только выборки, поэтому приходится немного постараться чтобы работа с данными была DML-подобной.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Считай, что строка таблицы — объект СУБД. G>>Я могу так считать, а сама СУБД начнат проверять разрешения от этого? G>>Проверки все равно ложатся на клиентский код независимо от того как я считаю.
A>Ты не прав.
В чем?
У вас проверки RLS не в коде? Это сама субд делает? Покажите мне эту субд.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
C>>>1) Контроль доступа. VD>>И что с ним? C>Сложно сделать на уровне чистых данных.
<крик с галерки>
А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.
</крик с галерки>
C>Реплики БД — это исключительно кривой хак.
Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили
Здравствуйте, Tom, Вы писали:
Tom>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента. Tom>От клиента до сервера БД. ТАк же как и в самих запросах. Так что эти разделения на BL/DAL предлагаю сразу забыть.
Это звучит примерно так: я не понимаю смысла разделения приложения на слои, поэтому предлагаю эти разделения сразу забыть. Да уж, чего только люди не придумают для оправдания собственных ошибок или непонимания сути обсуждаемых вещей.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Потому что серебрянной пули на практике не бывает. Tom>Если на все задачи по работе с данными у тебя есть один единственно правильный ответ, то что то тут не так. Tom>Если не согласен предлагаю перейти от розового слоника в вакууме перейти на примеры. Обсуждать воздух очень тяжело.
Смотри программирование ошибочно, так как на любой вопрос автоматизации все предлагают запрограммировать ее.
СУБД ошибочны так как для хранения данных предлагают использовать их.
Еще примеры приводить?
Запросы не панацея — способ обработки данных. Его прекрасно можно использовать для обработки данных вместо дурацкого запаковывания всего и все в объекты и попыток использовать ООП для обработки данных.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.
Дело в том, что нужно обеспечивать и контроль данных — чтобы любой пользователь не мог подсмотреть номер кредитки директора.
C>>Реплики БД — это исключительно кривой хак. KV>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили
Скажи, и нравится тебе как работает Лотус?
Здравствуйте, Tom, Вы писали:
G>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject). Tom>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так:
X GetById(int id)
{
return (from x in xs where x.id = id select x).Fitst();
}
...
... GetById(GetId())
если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?
Ты погляди на на код своих хранимок. Там ведь обработка данных, а не все эти GetById. Почему?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Реплики БД — это исключительно кривой хак. VD>Ыыыыыуууыыыйй! Я плякаль! А еще говорят умер юмор на нашей эстраде. VD>Ладно. Спорить на таком уровне я не готов. Пилите Шура! Пилите! Они золотые. (с)
А ведь на вопрос как мне такое сделать ты так и не ответил.
C>>И что дальше? Почему я должен молиться на БД и считать её недостяжимым идеалом, попытка повторить часть функций которого является величайшей дерзостью? VD>Я даже не знаю. Это же твоя идея. От тебя и ответа ждать.
Я это делаю с помощью ORM — в кэше хранятся объекты, обладающие свойством идентичности. Соответственно, и никаких проблем.
VD>Если ты не верно сформулировал вопрос и хочешь спросить почему не стоит повторять функции СУБД в своем приложении, то я могу ответить. Потому, что это море очень серьезного кода воспроизвести качественно который ты не сможешь. Будет жалкая пародия, в лучшем случае.
Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат.
Здравствуйте, Cyberax, Вы писали:
VD>>Если ты не верно сформулировал вопрос и хочешь спросить почему не стоит повторять функции СУБД в своем приложении, то я могу ответить. Потому, что это море очень серьезного кода воспроизвести качественно который ты не сможешь. Будет жалкая пародия, в лучшем случае. C>Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат.
Ты наверное не понял что использование DML позволяет вообще не тянуть на клиент никакие данные, материализовываться выборки будут только с целью отображения.
Следовательно не понадобится идентичность объектов, оптимистичные блокировки и другие гадости.
Кеш станет предельно простым, так как объекты в кеше будут неизменяемыми (так как они получены только с целью отображения) и синхронизировать надо будет в одну сторону, что элементарно делается по LastModified.
Здравствуйте, gandjustas, Вы писали:
C>>Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат. G>Ты наверное не понял что использование DML позволяет вообще не тянуть на клиент никакие данные, материализовываться выборки будут только с целью отображения.
"Вообще не тянуть на клиент никакие данные" — это смешно.
У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?
Если нам не помогут, то мы тоже никого не пощадим.
