Здравствуйте, VladD2, Вы писали:
A>>Это очень интересная задача, но у меня другая — кеширование на клиенте данных полученных от сервера. VD>А я об этом не говорил.
Здравствуйте, adontz, Вы писали:
A>>>Это очень интересная задача, но у меня другая — кеширование на клиенте данных полученных от сервера. VD>>А я об этом не говорил.
A>А что мешает?
1. Меня это не интересует.
2. Говорить об этой задаче абстрактно нет смысл, так как есть много стратегий реализации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>А что мешает? VD>1. Меня это не интересует. VD>2. Говорить об этой задаче абстрактно нет смысл, так как есть много стратегий реализации.
Здравствуйте, VladD2, Вы писали:
VD>Ну, и что — это за фигня?
Это называется эмулируем средствами имеющимися в наличии.
VD>Гоюки.
Я не думаю что в вопросе идентичности интерфейсов на этот гуид заложита такая уж фатальная логика, так как смысл его необходимости не вполне очевиден.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>>>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз. G>>>>А с какой целью её читать вообще? A>>>В моём случае, для подсказок при вводе данных. G>>Каких подсказок?
A>Что значит каких? Удобных Какая разница? Данные надо прочесть, вот и всё. Если Linq-образный подход не поддерживает чтение в нужном виде, не надо мне доказывать, что подсказки личшние.
Так ты опиши в каком виде тебе нужно прочесть данные (какие у тебя уже есть и какие нужно получить) и тебе сразу же покажут как это сделать в разы лучше на Linq, чем на любом супер-мега DAL.
Здравствуйте, gandjustas, Вы писали:
G>Так ты опиши в каком виде тебе нужно прочесть данные (какие у тебя уже есть и какие нужно получить) и тебе сразу же покажут как это сделать в разы лучше на Linq, чем на любом супер-мега DAL.
Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!
Здравствуйте, adontz, Вы писали:
A>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!
Это тебе уже объясняли. В задницу твои объекты и читай за один раз написав соответствующий запрос.
Что не понятно в этот ответе?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!
Если не понятен мой первый (точнее 30-ый) ответ, то поясню по-другому...
То что ты описал не задача, а твое (никудышное на наш взгляд) решение какой-то более общей задачи. Вот ее и опиши. Опиши, что ты хочешь сделать с получаемой информацией.
А если захочется еще раз рассказать о каких-то там объектах отображаемых на какие-то там связи вроде многое ко многим, то сразу забей... не повторяйся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Так ты опиши в каком виде тебе нужно прочесть данные (какие у тебя уже есть и какие нужно получить) и тебе сразу же покажут как это сделать в разы лучше на Linq, чем на любом супер-мега DAL.
A>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!
Давай в терминах данных, а не в терминах объектов.
Получается просто надо прочитать содержимое таблицы?
Думаешь супер-мега DAL будет в данном случае обычного запроса (хоть Linq, хоть SQL)?
ЗЫ. Linq2SQL такое выполняет сам, в EF такое не нужно, там явно не работать с таблицами связей нельзя, оно отображаются на связи типа "многие-ко-многим" модели данных.
Здравствуйте, VladD2, Вы писали:
A>>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?! VD>Это тебе уже объясняли. В задницу твои объекты и читай за один раз написав соответствующий запрос. VD>Что не понятно в этот ответе?
Здравствуйте, gandjustas, Вы писали:
A>>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?! G>Давай в терминах данных, а не в терминах объектов. G>Получается просто надо прочитать содержимое таблицы?
Не просто прочитать содержимое, а прочитать и сохранить в объектах. Надолго сохранить, закешировать например.
G>Думаешь супер-мега DAL будет в данном случае обычного запроса (хоть Linq, хоть SQL)?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?! G>>Давай в терминах данных, а не в терминах объектов. G>>Получается просто надо прочитать содержимое таблицы?
A>Не просто прочитать содержимое, а прочитать и сохранить в объектах. Надолго сохранить, закешировать например.
Это к запросам отношения не имеет.
G>>Думаешь супер-мега DAL будет в данном случае обычного запроса (хоть Linq, хоть SQL)?
A>Что? Придложение несогласованное какое-то...
Да, че-то слово пропустил.
Думаешь супер-мега DAL будет в данном случае изящнее обычного запроса (хоть Linq, хоть SQL)?
Здравствуйте, gandjustas, Вы писали:
A>>Не просто прочитать содержимое, а прочитать и сохранить в объектах. Надолго сохранить, закешировать например. G>Это к запросам отношения не имеет.
Да, беда как раз в том, что имеет отношение, потому что изначально неструктурированные запросы, содержащие только то что надо в месте вызова, для кеширования не подходят.
Я уже даже объяснил почему, привёл пример проблемы http://www.rsdn.ru/forum/message/3358676.1.aspx
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Не просто прочитать содержимое, а прочитать и сохранить в объектах. Надолго сохранить, закешировать например. G>>Это к запросам отношения не имеет.
A>Да, беда как раз в том, что имеет отношение,
Это в твоем случае имеет, такова особенность твоей реализации. В мой реализации способ получения результатов запроса на их обработку не влияет.
A>изначально неструктурированные запросы, содержащие только то что надо в месте вызова, для кеширования не подходят.
Linq запросы неструктурированы? Почему не подходят для кеширования?
В многопользовательской среде несогласованность отображаемых данных из БД- нормальное явление. С этим не надо бороться, это надо учитыватьпри проектировании интерфейсов.
G>>Думаешь супер-мега DAL будет в данном случае изящнее обычного запроса (хоть Linq, хоть SQL)? A>Да чё тут думать, у меня он уже есть
Мои соболезнования.
Здравствуйте, gandjustas, Вы писали:
A>>Да, беда как раз в том, что имеет отношение, G>Это в твоем случае имеет, такова особенность твоей реализации. В мой реализации способ получения результатов запроса на их обработку не влияет.
Ты так и не понял, дело не в способе получения, а в полноте самих данных.
A>>изначально неструктурированные запросы, содержащие только то что надо в месте вызова, для кеширования не подходят. G>Linq запросы неструктурированы? Почему не подходят для кеширования?
G>В многопользовательской среде несогласованность отображаемых данных из БД- нормальное явление. С этим не надо бороться, это надо учитыватьпри проектировании интерфейсов.
Боюсь что ты не прав. Можно обеспечить согласованность данных, нельзя обеспечить актуальность.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Да, беда как раз в том, что имеет отношение, G>>Это в твоем случае имеет, такова особенность твоей реализации. В мой реализации способ получения результатов запроса на их обработку не влияет.
A>Ты так и не понял, дело не в способе получения, а в полноте самих данных.
Ну давай по-кругу. Что есть и что надо получить?
Только пожалуйтса не в терминах объектов.
A>>>изначально неструктурированные запросы, содержащие только то что надо в месте вызова, для кеширования не подходят. G>>Linq запросы неструктурированы? Почему не подходят для кеширования? A>Потому что согласованность нарушена.
Согласованность чего?
A>>>Я уже даже объяснил почему, привёл пример проблемы http://www.rsdn.ru/forum/message/3358676.1.aspx
G>>В многопользовательской среде несогласованность отображаемых данных из БД- нормальное явление. С этим не надо бороться, это надо учитыватьпри проектировании интерфейсов. A>Боюсь что ты не прав. Можно обеспечить согласованность данных, нельзя обеспечить актуальность.
Это словоблудие.
Согласованность можно обеспечить если запрашиваться все сразу (JOIN), но сценрии работы зачастую не позволяют это сделать. Причем это абсолютно не зависит от технологий доступа к данным.
Здравствуйте, gandjustas, Вы писали:
G>Согласованность можно обеспечить если запрашиваться все сразу (JOIN), но сценрии работы зачастую не позволяют это сделать. Причем это абсолютно не зависит от технологий доступа к данным.
Ты не прав. Согласованность можно обеспечить даже запрашивая по частям, если сохранять ссылочную структуру.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Согласованность можно обеспечить если запрашиваться все сразу (JOIN), но сценрии работы зачастую не позволяют это сделать. Причем это абсолютно не зависит от технологий доступа к данным.
A>Ты не прав. Согласованность можно обеспечить даже запрашивая по частям, если сохранять ссылочную структуру.
Какую ссылочную структуру?
Как обеспечить согласованность когда между отображением поста в списке и попыткой открыть его модератор успевает его удалить?
Или тот же пример с городами: запросили сначала список городов с количеством кастомеров, потом запрашиваем катомеров из конкретного города. Между запросами другой пользователь поменял одному из кастомеров в город. Какая ссылочная структура поможет отследить изменение количества в двух городах?
Здравствуйте, adontz, Вы писали:
IT>>Ты сам утверждаешь, что один запрос по твоей логике следует считать корректным, а другой некорректным. Откуда базе данных это знать?
A>Нет. Я лишь сказал, что когда хочу получить информацию об элементе по его идентификатору, потому что в другом месте уже были ссылки на элемент с данным идентификатором, то отсутсвие элемента — проблема целостности данных.
Перечитай ещё раз определение целостности данных. Покажи мне где там идёт речь о получении информацию об элементе по его идентификатору, потому что в другом месте уже были ссылки на элемент с данным идентификатором.
IT>>И вообще, для многих это покажется крамолой, но с появлением технолоний вроде linq DAL, потеряв свои первоначальное продназначение вообще должен отмереть за ненадобностью.
A>А, ну тогда помоги Владу ответить, потому что он что-то не справляется, как нам быть с кешированием на удалённом толстом клиенте. Начинать тут A>http://www.rsdn.ru/forum/message/3358676.1.aspx
Здравствуйте, adontz, Вы писали:
IT>>Ну да, я так и думал. Всё-таки каша в голове. Рома, DAL — это слой изолирующий работу с БД в терминах БД от остальной части приложения. Другими словами, в коде мы используем типизированные данные, а с БД вынуждены работать используя строковые константы. DAL был придуман иключительно как средство, позволяющее изолировать работу со строками в одном месте, которое будет легче контролировать. Всё! Другого назначения у DAL нет и никогда не было.
A>Это не DAL, это ORM.
Рома, ты прежде чем спорить ознакомился бы сначала с общепринятой терминологией. Начни отсюда.
Если нам не помогут, то мы тоже никого не пощадим.
Какая разница? Данные надо прочесть, вот и всё. Если Linq-образный подход не поддерживает чтение в нужном виде, не надо мне доказывать, что подсказки личшние.
Если нам не помогут, то мы тоже никого не пощадим.
