Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз. G>>А с какой целью её читать вообще?
A>В моём случае, для подсказок при вводе данных.
Каких подсказок?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Как схемы БД, так и кода для работы с БД. Да, вот забыл упомянуть, что делать с row level security? Боюсь, если хранимки не генерировать, будет беда. G>>тогда метаинформация нужна по мощности сравнимая с SQL, такое могут еще нескоро придумать. Может быть MSовский Oslo таким будет.
A>Если не пытаться генерировать совсем всё-всё-всё, метаинформация может получится довольно таки простой.
Если хочется генерировать хранимки, вьъхи, триггеры, индексы, то метаинформация будет сравнимой с SQL DDL.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
G>>Не-не-не, дэвид блейн, не-не. Не надо ООП тянуть в организацию логики программы. Для логики подходит модель SOA. VD>SOA — это очередной базворд. Раньше это называли RPC, но потом в этом названии нашли фатальный недостаток .
SOA — принции построения взаимодействия компонент. То что раньше было RPC теперь веб-сервисы.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, MozgC, Вы писали:
G>>>Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования. MC>>Нет, целостность данных — должна контролироваться в DAL и БД. Отствие записи с нужным ID — это исключительная ситуация, и DAL в таком случае должен выбрасывать исключение. И вот дальше уже да, дело бизнес-логики как обрабатывать это исключение.
A>Собственно, если мы договорились о том, что "Отсутвие записи с нужным ID — это исключительная ситуация" то бизнес-логике думать уже не о чем. Надо культурно уведомить об ошибке.
Это у вас исключительная ситуация, а у меня пустая выбрка из dal — ситуация вполне нормальная.
А что вы будете делать если "Отсутвие записи с нужным ID" будет исключительной ситуацией в одном сценарии, и вполне нормальной ситуацией в другом?
Здравствуйте, VladD2, Вы писали:
VD>А смысл? Основные функции записей — это сравнение и копирование. Как этому помогут интерфейсы?
class A:IValue
{
public int Value {get;set;}
public IValue Copy(){...}
public override bool Equals(object obj) { if(obj is IValue) ...}
}
VD>Да и опять же сгенерировать одинаковые гуиды для одинаковых записей нельзя.
struct A { int a; }
struct B { int a; }
Я верю что для них можно сгенерировать одинаковые гуиды.
VD>Это нонсенс.
Из строки любой длинны нельзя выбрать 128 бит?
VD>Требование одно. Структурная идентичность. Гуиды должны совпадать только у тех типов которые структурно идентичны.
Мы сейчас говорим о net 4.0 или о чем то абстрактном? И что же произойдет если я зланомеренно поставлю гуид IEnemerabla какому нибудь своему интерфейсу?
Здравствуйте, VladD2, Вы писали:
A>>Влад, конкретному клиенту может потребоваться много данных, но даже это количество может составлять лишь малую часть от общего объёма БД. VD>Ну, дык определись. Может вообще ничего кэшировать/реплицировать не надо. Может надо кэширова/реплицировать только часть БД.
Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию.
A>> А реплицировать гигабайты информации по международным каналам просто дорого. VD>Я не знаю, что у вас в Грузии. У нас это трафик не так дорог. Да и если у фирмы гигабайтный трафик в день, то она очень богата. А если это вся БД, то синхронизация в день будет копеечной. Так что не выдумывай.
Влад, нужен не просто канал, а надёжный канал. И весь объём данных генерируется не равномерно за 24 часа. Вобщем, решение не реальное.
A>> Твои ответы наводят на мысль что мегапередовая система совершенно не подходит для создания клиент-серверных приложений. VD>Это ты пытаешся найти какие-то крайние ситуации. БД и сервер приложений на разных частях мира — это как минимум ненадежно, и уж точно неразумно.
Я тебе ясно написал что БД и сервер приложений очень даже рядом. Далеко — толстый клиент.
VD>Если репликация не подходит, то речь можно вести только о варианте запроса текущих данных. VD>А если что-то делать через задницу, то конечно можно обосновать любое самое кривое решение.
Пока что через задницу выглядит исключительно твой вариант.
Здравствуйте, IT, Вы писали:
IT>Ты сам утверждаешь, что один запрос по твоей логике следует считать корректным, а другой некорректным. Откуда базе данных это знать?
Нет. Я лишь сказал, что когда хочу получить информацию об элементе по его идентификатору, потому что в другом месте уже были ссылки на элемент с данным идентификатором, то отсутсвие элемента — проблема целостности данных.
IT>И вообще, для многих это покажется крамолой, но с появлением технолоний вроде linq DAL, потеряв свои первоначальное продназначение вообще должен отмереть за ненадобностью.
А, ну тогда помоги Владу ответить, потому что он что-то не справляется, как нам быть с кешированием на удалённом толстом клиенте. Начинать тут http://www.rsdn.ru/forum/message/3358676.1.aspx
Здравствуйте, IT, Вы писали:
A>>DAL отличается от бизнес-логики назначением. DAL поддерживает инфрастурктуру: целостность данных, транзакции, права доступа на уровне строк. А вот как этим всем пользоваться решает BL. IT>Ну да, я так и думал. Всё-таки каша в голове. Рома, DAL — это слой изолирующий работу с БД в терминах БД от остальной части приложения. Другими словами, в коде мы используем типизированные данные, а с БД вынуждены работать используя строковые константы. DAL был придуман иключительно как средство, позволяющее изолировать работу со строками в одном месте, которое будет легче контролировать. Всё! Другого назначения у DAL нет и никогда не было.
Здравствуйте, IT, Вы писали:
A>>Вообще-то исключения надо ловить, а не только кидать IT>Ловить для того, чтобы построить на них логику приложения? IT>Исключения ловить нужно только в одном случае, чтобы показать сообщение об ошибке пользователю.
а если ты не заметил, речь шла о ситуации, которая считается ошибочной.
Здравствуйте, IT, Вы писали:
A>>Влад, ты говоришь несусветную глупость. Всё преимущество исключений как раз в том, что не надо передавать диагностическую иформацию через весь стек, заодно, не забывая её проверять. Предлагать менять исключения на коды возврата это ахинея редостная. IT>Возврат базой данных пустого рекордсета — это самая что ни на есть штатная ситуация. Исключительной она может стать (а может и не стать) только когда такое решение примет BL. Ты же предлагаешь кидать исключения в совершенно штатной ситуации. Бред.
Описанная ситуация не может быть штатной, так как нарушена целостность данных Хотя, если для тебя нарушенная целостность данных штатная ситуация...
Здравствуйте, gandjustas, Вы писали:
A>>>>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз. G>>>А с какой целью её читать вообще? A>>В моём случае, для подсказок при вводе данных. G>Каких подсказок?
Что значит каких? Удобных Какая разница? Данные надо прочесть, вот и всё. Если Linq-образный подход не поддерживает чтение в нужном виде, не надо мне доказывать, что подсказки личшние.
Здравствуйте, dotneter, Вы писали:
VD>>А смысл? Основные функции записей — это сравнение и копирование. Как этому помогут интерфейсы? D>
D>class A:IValue
D>{
D> public int Value {get;set;}
D> public IValue Copy(){...}
D> public override bool Equals(object obj) { if(obj is IValue) ...}
D>}
D>
Ну, и что — это за фигня? И это вместо примитивнейшей структуры данных. Это никуда не годится.
D>Из строки любой длинны нельзя выбрать 128 бит?
Можно но это будет не уникального значение, а хэш-значение. И никто не гарантирует, что это хэш-значение не пересечется, ни с другими хэш-значениями, ни с другими гуидами.
VD>>Требование одно. Структурная идентичность. Гуиды должны совпадать только у тех типов которые структурно идентичны. D>Мы сейчас говорим о net 4.0 или о чем то абстрактном? И что же произойдет если я зланомеренно поставлю гуид IEnemerabla какому нибудь своему интерфейсу?
Гоюки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>SOA — принции построения взаимодействия компонент. То что раньше было RPC теперь веб-сервисы.
SOA — это драцкий базворд за которым нет ничего нового. К компонентам (кстати "компонентов", а не "компонента") SOA не имеет никакого отношения. Расшифровывается этот базворд как "архитектура ориентированная на сервисы". Это тоже самое что серверы ориентированные на RPC. Дурацкий базвордов придумать можно миллионы (что и делаеют конторы вроде МС каждый день), но толку от этого не будет, так как ничего принципиально нового от этот не появится.
SOA родилась в момент когда в МС полностью отчаялись протащить DCOM в область разработки серверов приложений. Тогда они понял, что общаться с серверами намного проще по средствам RPC (без сохранения состояния между вызовами на сервере). Тогда срочно придумали веб-сервисы, а чтобы все это круто звучало и никто не догадался, что это просто откат к более "примитивной" технологии и признание недееспособности ООП в области организации распределенных вычислений назвали все это SOA. Как и любой базворд это звучит красиво, не понятно. Что еще нужно чтобы завуалировать собственную глупость?
ЗЫ
Мне эта тема не интересна. Предлагаю ее закрыть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию.
Я не хочу с тобой спорить. Считай как хочешь.
A>Влад, нужен не просто канал, а надёжный канал. И весь объём данных генерируется не равномерно за 24 часа. Вобщем, решение не реальное.
Чушь натуральная. Надежнее Интернет ничего быть не может. Если твой сервер стоит в приличном датацентре (да даже если хоть в каком-то) то тебе обеспечен надежный доступ на скорости 10 и более мегабит.
В прочем решения конечно могут быть разными. Но, на мой взгляд, самое глупое что можно придумать — это разнести сервер приложений и СУБД по разным частям Интерента и заниматься самопальным кэшированием. Решение будет априори не надежное и трудное в поддержке.
A>Я тебе ясно написал что БД и сервер приложений очень даже рядом. Далеко — толстый клиент.
Тогда ты вообще не ясно что обсуждаешь. Проблемы взаимодействия клиента и сервера приложений мы тут даже не обсуждаем. Кэширование данных на клиенте — это целиком прикладная задача. При современных скоростях интернета я вообще считаю это дурью. Gmail отлично продемонстрировал как должен работать современный софт. Лично я отказался от почтового клиента и читаю почту через веб-интерфейс Gmail-а.
A>Пока что через задницу выглядит исключительно твой вариант.
Я не понял того, что ты говоришь о клиенте. Конечно для клиента бессмысленно создавать реплики БД. Хотя Янус практически это и делает, так что это возможно. Я говорил о распределенной работе серверов.
Вот Киберакс явно занимается распределением серверов в Интернет. На мой взгляд — это плохая идея, но уж если ее следует реализовать, то репликация БД лучше чем самопальные кэши.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Влад, нужен не просто канал, а надёжный канал. И весь объём данных генерируется не равномерно за 24 часа. Вобщем, решение не реальное. VD>Чушь натуральная. Надежнее Интернет ничего быть не может. Если твой сервер стоит в приличном датацентре (да даже если хоть в каком-то) то тебе обеспечен надежный доступ на скорости 10 и более мегабит.
Бугага. Региональные клиенты тоже в приличных датацентрах?
A>>Я тебе ясно написал что БД и сервер приложений очень даже рядом. Далеко — толстый клиент.
VD>Тогда ты вообще не ясно что обсуждаешь. Проблемы взаимодействия клиента и сервера приложений мы тут даже не обсуждаем. Кэширование данных на клиенте — это целиком прикладная задача. При современных скоростях интернета я вообще считаю это дурью. Gmail отлично продемонстрировал как должен работать современный софт. Лично я отказался от почтового клиента и читаю почту через веб-интерфейс Gmail-а.
Я очень за тебя рад по поводу GMail, но тот факт что Влад читает почту через GMail не отменяет существования толстых клиентов. Если вернуться к сути вопроса, при твоём способе общения сервера приложений и базы данных, сервер приложений не сможет выдать клиенту ничего, что можно было бы закешировать. Скорее всего тебя и вовсе потянет на создание IQueryable over WebService. Соответсвенно прикладная задача кеширования становится неразрешимой. То есть твоя великая мегаидея, при ближайшем рассмотрении более или менее хорошо подходит только для вебсайтов.
VD>Я не понял того, что ты говоришь о клиенте. Конечно для клиента бессмысленно создавать реплики БД. Хотя Янус практически это и делает, так что это возможно. Я говорил о распределенной работе серверов. VD>Вот Киберакс явно занимается распределением серверов в Интернет. На мой взгляд — это плохая идея, но уж если ее следует реализовать, то репликация БД лучше чем самопальные кэши.
Я не Киберакс и про распределённые сервера не говорил. Это очень интересная задача, но у меня другая — кеширование на клиенте данных полученных от сервера.
Здравствуйте, Cyberax, Вы писали:
C>1) Контроль доступа.
И что с ним?
C>2) Время синхронизации — у меня оповещения рассылаются меньше чем за секунду.
А почему репликация данных не может работать с той же скоростью? Секунда — это довольно много.
C>3) Простота клиента. У меня это просто приложение, которое пользователь запускает через WebStart. Пользователям не надо думать о файрволах, публичных IP и т.д.
Причем тут клиент? У тебя ведь сервер данные кэширует? Мы вообще что обсуждаем? Может я вас не верно понял?
Еще раз я говорю о том, что заниматься сложным кэшированием в сервере приложения неразумно. Если серверы вынуждены работать на разнесенными далеко друг от друга, лучше иметь локальные копии БД для каждого сервера которые будут синхронизироваться между собой. Это самый лучший и бескомпромиссный кэш.
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" и кладём его результаты в кэш.
А зачем часто изменяемые данные кэшировать. Такие данные я буду запрашивать каждый раз. Реч шла о чем-то что редко изменяется. Например о списке наменклатур. Бывает так, что они обновляются раз в месяц. В таких условиях тянуть описания продуктов из БД смысла нет. Хотя тоже стоит подумать, так как если этот список огромен, а каждый раз нужно вытаскивать всего 1-5 записей, то опять же кэш может оказаться бессмысленными.
В общем, кэш — это оптимизация. И надо сто раз подумать прежде чем ей заниматься. В отличии от этого реплика БД — это архитектурное решение. Он лишено проблем связанных с кэшировнием. Оно бескомпромиссно.
C>Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами.
То на что ты намекаешь — это болезнь под названием заменить БД кэшем в сервере приложения.
C>Предлагай решения.
Перестать дублировать работу сервера БД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Что значит каких? Удобных Какая разница? Данные надо прочесть, вот и всё. Если Linq-образный подход не поддерживает чтение в нужном виде, не надо мне доказывать, что подсказки личшние.
Что не поддерживает Linq?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Бугага. Региональные клиенты тоже в приличных датацентрах?
Причем тут клиенты? Еще раз. Я не гворил о связи с клиентами. Вообще!
Абзац вниз слабо было прочесть?
A>Я очень за тебя рад по поводу GMail, но тот факт что Влад читает почту через GMail не отменяет существования толстых клиентов. Если вернуться к сути вопроса, при твоём способе общения сервера приложений и базы данных, сервер приложений не сможет выдать клиенту ничего, что можно было бы закешировать.
Это зависит от логики приложения. Замечательный пример — Янус. Он построен по описываемой мной технологии, но при этом целенаправленно создает кэш сообщений на клиенте. Только такое кэширование — это технология, а не заплатки для хреновой производительности.
A> Скорее всего тебя и вовсе потянет на создание IQueryable over WebService.
Это фиговое решение с точки зрения безопасности. Слишком мощный инструмент, который может быть использован злоумышленниками.
A> Соответсвенно прикладная задача кеширования становится неразрешимой. То есть твоя великая мегаидея, при ближайшем рассмотрении более или менее хорошо подходит только для вебсайтов.
Неверные выводы. Я говорил только а серверной стороне.
A>Я не Киберакс и про распределённые сервера не говорил. Это очень интересная задача, но у меня другая — кеширование на клиенте данных полученных от сервера.
А я об этом не говорил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
