Здравствуйте, adontz, Вы писали:
A>Ты считаешь что должен быть только один Query?
Я считаю, что должен быть один Linq.
A>Я проектирую БД не под объекты, а под рефакторинг. или рефакторинг ты тоже отменил?
Да. Рефактринг — это процесс улучшения, а не цель дизайна БД.
A>Влад, то что ты описываешь, это склеротичная модель обращения с данными — прочитал и забыл, потому что ничего не получитсяя локально закешировать, даже в оперативной памяти.
А не стоит брать на себя еще и задачи кэширования. Пусть этим займется СУБД. У нее это отлично получается.
Но если есть уверенность, что данные не изменятся, то можно запросить их однажды, положить в локальную коллекцию и подключать с помощью локального join-а. Самое забавное, что при использовании linq — это будет совершенно прозрачно. Просто подсунь коллекцию другого типа и данные будут браться из нее. Ты можешь смешивать запросы к БД с запросами к локальным коллекциям. Нужно только понимать, что делаешь.
A>Возвращается ведь неизвестно что, нужное только в том месте, где возвращается.
Как это неизвестно что? Мы же ведь к таблицам обращаемся. Значит известно что.
A>Это хорошо для веба, где веб-сервер и сервер БД рядом. Для клиент-сервера подобный подхход неприемлем.
Да, ну. И в чем тут уникальность веб-а? И что значит рядом? У вас что СУБД в Америке, а сервер приложений в Китае?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами? VD>Ты мыслишь их понятиями. Ты уже достал своей идеей проецирования объектов на БД. По буквам Д О С Т А Л! VD>Это тупик. Счастливого пути в этом направлении.
Самое прикольное, что по сравнению с традиционными реляционными БД, такой тупик кажется всё более и более привлекательным.
Здравствуйте, VladD2, Вы писали:
A>>Влад, то что ты описываешь, это склеротичная модель обращения с данными — прочитал и забыл, потому что ничего не получитсяя локально закешировать, даже в оперативной памяти. VD>А не стоит брать на себя еще и задачи кэширования. Пусть этим займется СУБД. У нее это отлично получается.
Беда в том, что СУБД далеко и мне от её кеша не жарко.
VD>Но если есть уверенность, что данные не изменятся, то можно запросить их однажды, положить в локальную коллекцию и подключать с помощью локального join-а. Самое забавное, что при использовании linq — это будет совершенно прозрачно. Просто подсунь коллекцию другого типа и данные будут браться из нее. Ты можешь смешивать запросы к БД с запросами к локальным коллекциям. Нужно только понимать, что делаешь.
Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы.
Здравствуйте, adontz, Вы писали:
A>Беда в том, что СУБД далеко и мне от её кеша не жарко.
Далеко — это где?
VD>>Но если есть уверенность, что данные не изменятся, то можно запросить их однажды, положить в локальную коллекцию и подключать с помощью локального join-а. Самое забавное, что при использовании linq — это будет совершенно прозрачно. Просто подсунь коллекцию другого типа и данные будут браться из нее. Ты можешь смешивать запросы к БД с запросами к локальным коллекциям. Нужно только понимать, что делаешь.
A>Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы.
Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Беда в том, что СУБД далеко и мне от её кеша не жарко. VD>Далеко — это где?
На другом континенте, например.
A>>Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы. VD>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.
А какие именно данные устареют?
Здравствуйте, Cyberax, Вы писали:
C>На другом континенте, например.
То есть у вас сиквел в Интернет?
Надеюсь, хот через ВПН?
VD>>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют. C>А какие именно данные устареют?
Любые которые будут изменены.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Беда в том, что СУБД далеко и мне от её кеша не жарко. VD>Далеко — это где?
В другом городе, как и вебсервер хостящий веб-сервис. Обычное дело.
A>>Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы. VD>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.
А очень просто. Я получаю список городов в виде CityName, CustomerCount (именно так мне надо для отображения), а потом список клиентов в виде FirstName, LastName, CityName. В промежутке была исправлена ошибка ввода и одному из клиентов поменяли город. Штампы времени мне не помогут, у меня последняя версия данных таблицы Cities и последняя версия данных таблицы Customers. А вот несогласованность данных налицо. Что я могу с этим сделать? Я могу нажать Refresh в окне с Cities, вот и всё что я могу. Довольно дурацкая ошибка для технологии будущего.
Здравствуйте, VladD2, Вы писали:
C>>На другом континенте, например. VD>То есть у вас сиквел в Интернет? VD>Надеюсь, хот через ВПН?
У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей
VD>>>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют. C>>А какие именно данные устареют? VD>Любые которые будут изменены.
Я понимаю. Но КАК ты собираешься обнаружить то, что тебе нужно инвалидировать в кэшах? Общий механизм, пожалуйста.
Здравствуйте, Cyberax, Вы писали:
C>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей
Чем изобретать велосипеды проще иметь реплики БД. Тогда они будут по близости и всегда в актуальном состоянии. Это лучший вариант кэша.
C>Я понимаю. Но КАК ты собираешься обнаружить то, что тебе нужно инвалидировать в кэшах? Общий механизм, пожалуйста.
Например, при перехватывая операцию добавления записи в таблицу (предположим, что удаление и обновление в таблице запрещено).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей VD>Чем изобретать велосипеды проще иметь реплики БД. Тогда они будут по близости и всегда в актуальном состоянии. Это лучший вариант кэша.
Влад, конкретному клиенту может потребоваться много данных, но даже это количество может составлять лишь малую часть от общего объёма БД. А реплицировать гигабайты информации по международным каналам просто дорого. Твои ответы наводят на мысль что мегапередовая система совершенно не подходит для создания клиент-серверных приложений.
Здравствуйте, adontz, Вы писали:
A>Влад, конкретному клиенту может потребоваться много данных, но даже это количество может составлять лишь малую часть от общего объёма БД.
Ну, дык определись. Может вообще ничего кэшировать/реплицировать не надо. Может надо кэширова/реплицировать только часть БД.
A> А реплицировать гигабайты информации по международным каналам просто дорого.
Я не знаю, что у вас в Грузии. У нас это трафик не так дорог. Да и если у фирмы гигабайтный трафик в день, то она очень богата. А если это вся БД, то синхронизация в день будет копеечной. Так что не выдумывай.
A> Твои ответы наводят на мысль что мегапередовая система совершенно не подходит для создания клиент-серверных приложений.
Это ты пытаешся найти какие-то крайние ситуации. БД и сервер приложений на разных частях мира — это как минимум ненадежно, и уж точно неразумно.
Если репликация не подходит, то речь можно вести только о варианте запроса текущих данных.
А если что-то делать через задницу, то конечно можно обосновать любое самое кривое решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей VD>Чем изобретать велосипеды проще иметь реплики БД. Тогда они будут по близости и всегда в актуальном состоянии. Это лучший вариант кэша.
Нереально.
1) Контроль доступа.
2) Время синхронизации — у меня оповещения рассылаются меньше чем за секунду.
3) Простота клиента. У меня это просто приложение, которое пользователь запускает через WebStart. Пользователям не надо думать о файрволах, публичных IP и т.д.
Ни одна из существовавших 3 года назад (да и сейчас) технологий этого делать не позволяет.
C>>Я понимаю. Но КАК ты собираешься обнаружить то, что тебе нужно инвалидировать в кэшах? Общий механизм, пожалуйста. VD>Например, при перехватывая операцию добавления записи в таблицу (предположим, что удаление и обновление в таблице запрещено).
Я не про то.
Представь, что у нас есть две таблицы 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" и кладём его результаты в кэш.
Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами.
Здравствуйте, adontz, Вы писали:
A>BL не должен содержать код обработки нецелостных данных.
При чём здесь целостность? Целостность — это когда ты не можешь добавить или изменить данные в БД таким образом, чтобы не сломать их на предмет логической согласованности и правильности значений. Выборка данных к их целостности отношения не имеет. Ты сам утверждаешь, что один запрос по твоей логике следует считать корректным, а другой некорректным. Откуда базе данных это знать? DAL — это слой абстракции доступа к данным и о бизнес логике ему следует знать не больше чем самой базе. DAL — это вообще затычка, средство для того, чтобы собрать тараканов в одном месте и не давать им разбегаться по всему приложению. Вот что такое DAL, а ты приписываешь ему совершенно не свойственные для него функции.
И вообще, для многих это покажется крамолой, но с появлением технолоний вроде linq DAL, потеряв свои первоначальное продназначение вообще должен отмереть за ненадобностью.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, MozgC, Вы писали:
IT>>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.
MC>Нет, это называется использовать исключения там где нужно.
Исключения нужно использовать в исключительных ситуациях, в которых как правило программа не может продолжить выполнения. Пробрасывать исключение выше для последующей обработки называется построением логики приложения на использовании исключений. Практика крайне порочная, но хорошо лечится железной ленейкой.
IT>>Вот хороший пример. Можно ещё обсудить вариант с разрешением к доступу к файлу. Твой backup процесс пытается скопировать файл, а он недоступен, по твоей логике есть только один путь — кинуть исключение и прервать процесс. Такой бекапер будет выброшен сразу же после первой проблемы с потерей информации.
MC>Нет, по-моему логике такого не будет, не надо за меня говорить. По-моему логике при попытке скопировать файл выкинется исключение а бизнес-логика решит что делать дальше, к примеру повторить попытку позже или залогировать это или сообщить пользователю.
Читай выше. Ты строишь логику приложения на исключениях или ты с этим не согласен?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, MozgC, Вы писали:
MC>Удели пожалуйста 2 минуты, объясни почему за выбрасывание исключения из DAL при отсутствии темы с заданным ID нужно что-нибудь отрезать.
Потому что DAL отвечает за изоляцию доступа к данным и больше ни за что. Для БД твоя логика надо или не надо кидать исключение — темный лес. DAL в этом смысле не должен быть умнее.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>DAL отличается от бизнес-логики назначением. DAL поддерживает инфрастурктуру: целостность данных, транзакции, права доступа на уровне строк. А вот как этим всем пользоваться решает BL.
Ну да, я так и думал. Всё-таки каша в голове. Рома, DAL — это слой изолирующий работу с БД в терминах БД от остальной части приложения. Другими словами, в коде мы используем типизированные данные, а с БД вынуждены работать используя строковые константы. DAL был придуман иключительно как средство, позволяющее изолировать работу со строками в одном месте, которое будет легче контролировать. Всё! Другого назначения у DAL нет и никогда не было.
Аналогичный слой можно использовать не только для БД. Например, работу в вражеским веб-сервером тоже желательно завернуть в слой, переводящий доступ к сервису из терминов сервиса в термины нашего приложения.
Ключевое слово в DAL и подобных слоях — изоляция. А ты в своём определении DAL намешал в одну кучу всё подряд.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Влад, ты говоришь несусветную глупость. Всё преимущество исключений как раз в том, что не надо передавать диагностическую иформацию через весь стек, заодно, не забывая её проверять. Предлагать менять исключения на коды возврата это ахинея редостная.
Возврат базой данных пустого рекордсета — это самая что ни на есть штатная ситуация. Исключительной она может стать (а может и не стать) только когда такое решение примет BL. Ты же предлагаешь кидать исключения в совершенно штатной ситуации. Бред.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, MozgC, Вы писали:
MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?
Выделенное.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, VladD2, Вы писали:
VD>>Все зависит от логики. Если речь идет об исклчении, т.е. ошибке которая возникает в случае непредвиденных (заранее) обстоятельств, то конечно будет исключение и стандартная обработка.
MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?
То что производитель "должен быть" — деталь БЛ, незачем тащить её в dal.
Если нам не помогут, то мы тоже никого не пощадим.
