Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 18:12
Оценка: 227 (13) +5
Здравствуйте, Cyberax, Вы писали:

C> Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

Есть. Фундаментальная причина заключается ровно в том, что OODB жестко привязывает поведение и структуру к данным, а срок жизни данных сильно больше навязанного им поведения, и за их время жизни интерпретация меняется по многу раз. Так что привязывать какое-то конкретное поведение к данным — дурная затея. Во-первых, меняя в десятый раз поведение данные нужно оставлять неизменными. Во-вторых, добавляя новое поведение, надо его просто добавлять, а не менять старое и на накручивать поверх старого, при этом данные должны быть по прежнему неизменными. Ровно эта же причина является и фатальным недостатком классических ORM, там это просто меньше чувствуется, так как данные все-таки реально отделены и лежат в базе, и ничто не мешает навернуть еще одну модель сверху, после того как старая перестала устраивать, но это все равно конкретный косяк, который их рано или поздно похоронит.
Ну возьми реальное приложение, которое работает с данными, на кой байт тебе там полноценный граф объектов? У такой модели хорошо получается только добираться до одного элемента по индексу, но на самом-то деле нужно фильтровать, объеденять, сортировать, агрегировать, причем самым произвольным образом, а на всех этих операциях ОО сосет как промышленный пылесос, по сравнению с моделью старика Кодда. В плоть до того, что для решения таких задач в насквозь объектный C# вкрячили функциональный LINQ, так похожий на SQL, что с двух шагов не отличить.
Мало кому интересен просто список товаров, интересен этот список отфильтрованный и отсортированный по самым причудливым критериям, например по принадлежности к конкретному заказу... Но самое забавное, что заказ и список элементов заказа, практически ни в одном юзкейсе не нужны одновременно, так какого байта в объекте Order делает коллекция OrderItems, потому что "объектно"?
Такая объектность может далеко завести, к примеру, работает у нас сейлз в B2B магазине, для него вполне возможен такой граф объектов Region->Customer->Orders->OrderItems->Product->Vendor... ->Region, упс, граф-то цикличный... Хуже другое, после сейлза пришел вендор-менеджер, а ему от кастомера плясать не интересно, ему граф-то нужен ровно обратный Vendor->Products->OrderItems->Order->Customer. И это мы еще на какого-нибудь логистика не посмотрели, у которого регионы и счета кастомера начинаются прямо от OrderItems и конкретный заказ ему не интересен ему важны все OrderItems до четырех часов сегодняшнего дня, чтобы доставку на завтра спланировать по всем адресам.
В OODB и в ORM-ном графе объектов, еще на этапе проектирования приложения нужно не просто обозначить ничего не обязывающую связь один ко многим, между заказом и продуктами в него входящими, а явно сказать, что коллекция объектов OrderItems принадлежит объекту Order, хотя в 99% юзкейсов не понадобится подгружать Order и OrderItems одновременно и, максимум в 50% юзкейсов, это утверждение о принадлежности вообще имеет смысл, так как отбирать эти OrderItems надо совсем по другому критерию.
Безусловно, это все решаемые проблемы, можно заранее протоптать все пути, можно применить LazyLoading, чтобы подгружать только нужную часть объектов. Закрыть глаза, на то что нигде не контролируется, что подгружается только нужная часть. Прикрутить навороченый двухуровневый кеш, с хитрым механизмом контроля когерентности, чтобы победить стоимость поднятия объекта при навигационном доступе. Использовать, при необходимости, DTO, так как нельзя просто передать объект куда хочется ввиду наличия LL, который уволочет на ту сторону всю базу... И так далее в том же духе, дедка за репку, одно тянет другое, хотя в итоге получается в принципе рабочее решение, которым правда не очень удобно пользоваться, так как пути жестко протоптаны — ну что тут поделаешь зато объектно....
И весь этот зоопарк костылей нужен вместо того, чтобы просто сказать базе — "дай мне пожалуйста всех вендоров, продукты которых мы продали в таких-то регионах, на сумму больше Z у. е." и получить от нее ровно ту информацию, которая нужна (к слову, в виде объекта), а не полный граф от вендора до кастомера.
Возникает только один вопрос — задлянафига нужен этот граф объектов в OODB?!
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[4]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 08.09.08 12:50
Оценка: +4 -1 :))
Здравствуйте, kuj, Вы писали:

kuj>Отсутствуют:

kuj>наследование
kuj>поддержка value-типов
kuj>распределенное кэширование
Это все положительные стороны.

kuj>SaveOrUpdate механизм(!)

Есть.

kuj>Очень неудобно работать с транзакциями вне контекста.

И не нужно этого делать.

kuj>NHibernate очень прост в использовании в простых проектах в действительности.

Не прост, в действительности.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 16.09.08 11:10
Оценка: 26 (1) +2 -3
Здравствуйте, criosray, Вы писали:
C>Вы считаете, что Вы знаете что такое leaky abstractions?
Да, считаю.

S>>Абстракции в архитектуре есть всегда. Вообще вся архитектура — это выбор абстракций. Ты имел в виду, что любая абстракция может стать leaky?

C>Конечно.
C>Вы это серьезно? Ну и фантазия у Вас...
При чем здесь фантазия? Мальчик, сходи почитай хотя бы одноименную статью Спольски.

Поясняю для смелых подростков, на пальцах, что значит leaky в применении к lazy loading.

Весь смысл lazy loading — в том, чтобы спрятать от его пользователя информацию о том, когда именно происходит загрузка данных. Если программист видит, где именно происходит loading, то LL облажался. LL делает вид, что order.Items уже здесь и сейчас, а на самом деле они все еще в базе, и будут запрошены только когда я начну итерироваться по Items.

Ну так вот его leakyness состоит в том, что на самом деле есть существенная разница между "здесь и сейчас" и "всё еще в базе". Функционально разницы нет. А вот с точки зрения производительности — разница есть. И когда я буду делать вызов order.Items[i].StockItem.Name, он легко приведет к отдельному запросу на каждой итерации. И протечка будет ровно в том, что это приведет к чудовищной производительности данного решения. Это 100% аналог проблемы с конкатенацией строк, которую приводит Спольски.

И все способы борьбы с вот этой вот протечкой — это фактически отказ от абстракции. Вместо того, чтобы наивно итерироваться по order.Items, я буду должен отдать специальный cache hint и заставить ORM всё-таки залоадить данные энергичным способом. То есть никакого Lazy load уже нет, уже есть "forced lazy load". Всё, это и был щасливый конец LL.

Понимание причин протекания абстракции "persistence ignorance" оставляю в качестве домашнего задания.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 08.09.08 21:53
Оценка: 8 (1) +4 -1
Здравствуйте, kuj, Вы писали:

kuj>Linq2sql не является ORM, как я уже упоминал.

Это вообще вопрос религиозный. Скажем Хайлсберг linq2SQL считает вполне себе ORM-ом, а его мнение, все-таки, по авторитетнее твоего будет, хотя бы в силу авторства..
Поэтому я совершенно сознательно и использую термин lightweight ORM.

kuj>Что до всего остального это очень плохо, что этого там нету.

Очень хорошо, что нет, и очень правильно.

kuj>Нет кэширования — нет scalability, нет поддержки нормальных коллекций для мэппинга — нет гибкости и т.д.

Гибкость и масштабируемость — не задача ORM, это задача приложения. Поэтому меня и озлобляют ORM, которые занимаютсе тем, чем не должны, и в итоге от их "гибкости" только геморрой на всю голову.

kuj>NHibernate дает выбор — использовать или нет.

Лучше бы вообще не было, чем такой выбор.

kuj>Чем же это плюс?

Тем что предлагается подумать и решить задачу по другому.

kuj> Что я должен задумываться о persist`е объектов

Именно.

kuj>Есть случаи когда нужно.

Нету. Есть нежелание сделать по нормальному.

kuj>Что именно криво? Что не просто?

Все, от идеологии до языка запросов.

kuj>Давай с конкретными примерами и контр примерами на Linq2Sql.

Неинтересно.

kuj>Мы и так используем обертку надо оберткой надо оберткой и т.д. Вся архитектура ПО уже много лет как строится по принципу слоев.

Это повод увеличивать количество слоев что ли? В свое время была роскошная картинка — стэк вызовов в EJB при обращении к БД — там больше ста методов набегало, если мне память не изменяет — тоже видимо были любители все слоями оборачивать... Это к стати к вопросу о явовских ORM.. =))
Зачем использовать две сторонние библиотеки сомнительного качества, когда можно использовать одну, которая идет вместе со студией?
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.09.08 07:47
Оценка: 26 (1) +3 -1
Здравствуйте, Cyberax, Вы писали:
C>Ты жалуешься на то, что .NET в обязательном порядке проверяет индексы массивов?
Нет, не жалуюсь. И вот почему:
1. В большинстве случаев обработка элемента стоит значительно дороже, чем проверка индекса при его получении. Это означает, что улучшить производительность путем отказа от проверки можно только незначительно.
2. В большинстве их тех случаев, когда обработка элемента очень дешевая по сравнению с его получением, джит устраняет лишние проверки
3. В остальных случаях я вынужден смириться с тем, что мне навязывают гарантию defined behavior ценой снижения производительности
C>А ведь то же самое, по сути — замедление в некоторых случаях может быть очень заметным по сравнению с нативным кодом.
Ну, во-первых, настолько заметного замедления на индексах получить вообще невозможно. Напомню, что мы говорим о двух-трех десятичных порядках разницы.
Во-вторых, проверка индексов дает мне функциональное преимущество. Это понятно? А LL дает мне всего лишь повязку на глаза, чтобы я не видел, когда данные будут загружены.

S>>1. Мы наконец поняли, какие объекты мы трогаем в рамках часто используемых use-case, и специальными хинтами вынуждаем ORM выполнить раннюю загрузку

C>Да, именно этот сценарий и есть mature.
Отлично. А что нам мешало понять сразу, какие объекты нам нужны? Резервирование товара — не rocket science; всё равно мы придем к тому же самому, только в профиль.

C>Вдобавок, тут надо ещё добавить, что нас интересуют не все наиболее часто используемые use-case'ы, а только самые тормозящие.

Это ты как раз перешел к п.2 моего ответа.

C>Их обычно совсем немного, это скорее всего будут какие-то выборки, работающие с большим числом элементов. А методы типа add_order/remove_order/assign_product_to_order будут прекрасно работать что с LL, что без него.

В принципе да; атомарные изменения по ID объекта работают приемлемо, поскольку LL фактически делает ту же самую работу, что и eager load.

C>Так как разница между одной SQL-командой или, скажем, тремя — ничтожна, если они вызываются всего несколько раз в секунду.


C>На нагруженных путях ещё может быть и оптимизированный ручной SQL и специальная обработка запросов. На то они и нагруженные пути.

Непонятно, почему не начать с того, чтобы честно разделить фазу получения данных и фазу их обработки, вместо того, чтобы убеждаться, что система не работает.
C>Зато при этом за счёт того, что в редких use-case'ах не надо заниматься premature-оптимизацией, имеем выигрыш в общем времени разработки.
Непонятно, что тут есть оптимизация. Я же не предлагаю сразу начинать с оптимизированного вручную SQL. Я просто предлагаю писать код в другом стиле.
Объем кода получится тот же самый; поэтому неясно, за счет чего мы проиграем во времени разработки.

S>>Не понял. Где экономия-то? Если нам невозможно сказать заранее, каких объектов, то мы просто будем вынуждены их загружать.

C>Ну да, в виде отдельных запросов, с поведением изоморфным LL.

C>Необязательно. Например, у меня есть условия, которые в SQL записываются в виде килобайтного кода.

Вот это интересно. Расскажи — попробуем отделить девиации от сознания.

C>И это очень быстро превращает схему БД в некий аналог Ктулху.

Правда что ли? А введение "недозаполненных" прокси-классов для оптимизации выборок в ORM не превращает схему маппинга в Ктулху?

C>Список — это вообще последнее дело. Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

Тоже хорошо.

C>От объектного подхода нам нужны графы объектов, которые ведут себя как графы объектов.

Вот тут опять непонятно. Лично меня всегда напрягало, что для разных юзкейзов нужны разные графы объектов. Вот в РСУБД с этим все очень хорошо: кодд выполнил домашнее задание по реляционной алгебре. Я конструирую нужную реляцию, а сервер обеспечивает мне ее выполнение. Я никак не ограничен набором хранимых таблиц в своих манипуляциях. А ОРМ предполагает, что я придумаю некий единый граф объектов, и всю жизнь приложения буду с ним работать. Я не могу получить напрямую граф из префектов и студентов, я вынужден тащить объекты групп, которые их объединяют. И навигироваться вдоль этого графа. А если мне не нравятся длинные пути, то мне придется вручную прокладывать шорткаты и следить за их обновлением.

C>Lightweight ORM я лично пробовал, и может кому-то и нравится возиться с ними, оптимизируя каждый уголок.

Непонятно, что такое "оптимизировать каждый уголок"
C> Но мне они просто не приносили существенной выгоды при увеличении объёмов ручной работы (читать: "мест для ошибок").
Непонятно, откуда увеличение объемов ручной работы. Это ты про написание самодельного кэша и LL?

C>Идеально подошли бы гибридные OODB+RDB, но нет их сейчас нормально на рынке, что тут сделать.

Ты знаешь, я даже в ООДБ как-то сомневаюсь. Точнее, я пока вижу мало способов существенно улучшить нынешнюю ситуацию путем внедрения ООДБ. Так, чтобы это не превратилось в плохую копию РДБ. Я бы понял, если бы удалось получить нормальную компонентную модель.
C>Я вот 90% еды сейчас палочками ем. Это удобнее, чем вилка!
Открой для себя прелесть борща
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.09.08 03:16
Оценка: 6 (1) +3
Здравствуйте, Cyberax, Вы писали:

C>Опять абсолюты. На практике (лично мне), например, очень часто удобно запросом выделить нужные объекты и работать с ними. LL работает тут как удобный "парашют" для тех случаев, когда нужно взять несколько незагруженных объектов.

Это очень дорогой парашют. Лично мне он больше напоминает мышеловку.
C>И обычно такая стратегия прекрасно работает. Если она перестаёт прекрасно работать — то начинаем оптимизировать начальную загрузку. Т.е. начинаем оптимизацию, когда она mature.
Что значит "когда она mature"? Я вижу два варианта трактовки "LL optimization maturity":
1. Мы наконец поняли, какие объекты мы трогаем в рамках часто используемых use-case, и специальными хинтами вынуждаем ORM выполнить раннюю загрузку
2. Мы убедились, что на реальных объемах LL ведет себя отвратительно, в отличие от нашей тестовой базы с 17 объектами, и заказчик стоит с топором у нас за плечами.
В итоге, мы имеем отсутствие LL на основных путях работы системы (и наш код эквивалентен загрузке датасетов с точностью до синтаксиса), и всё еще неприлично тормозную реализацию редких юз-кейзов.

C>Кстати, возможны и ситуации, когда LL экономит время. Например, если нам достоверно известно, что в ходе выполнения метода понадобится подгрузить всего несколько объектов. Но невозможно заранее сказать каких.

Не понял. Где экономия-то? Если нам невозможно сказать заранее, каких объектов, то мы просто будем вынуждены их загружать.
А вообще, ситуация "невозможности заранее" в некотором смысле искусственная. Это опять про девиации сознания, вызванные инструментом.
Поясню тезис: когда приложение проектирует программист-реляционщик, он всё время мыслит в терминах РСУБД и запросов. Когда ему нужно отбирать объекты по сложному критерию, он сразу думает о дополнительном поле (возможно, вычисляемом). Если ему нужно выводить произвольно отсортированный список, он придумает дополнительное поле "порядок для вывода". Связный список будет последним, что он станет рассматривать — потому что для его доставания нужно O(N) запросов.

Классический ООП программист думает наоборот: подсознательно он считает самой долгой операцией поиск, а самой быстрой — разыменование указателя. ОРМ поддерживают в нем эту иллюзию; в итоге он конструирует навигационно-ориентированную систему.

Вот тогда действительно, оказывается, что чтобы понять, что загружать B, нужно сначала загрузить A. Ссылки-с.
Вблизи всё выглядит правильно: как же еще обходить список, кроме как при помощи LL? Чуть подальше всё выглядит по-другому: список — противоестественная конструкция для БД, именно потому, что невозможно заранее сказать, что загружать. Приложение должно быть спроектировано так, чтобы заранее можно было сказать, что загружать. Это инженерная задача.

C>В том-то и дело, что справляются хуже. На практике нужна смесь реляционного и объектного подхода.

А что именно от объектного подхода нам нужно? Не могут ли это обеспечить lightwaight ORM?

C>Все мои приложения под этот класс подходят. Обычно на ORM прекрасно пишется 95% кода, с остальными 5% в виде ручного SQL.

А мы в общаге 95% еды ели алюминиевыми ложками. Потому что вилка была всего одна
На что похожи все предметы, когда у тебя молоток?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 19.09.08 01:42
Оценка: 4 (2) +2
Здравствуйте, <Аноним>, Вы писали:

А можно я, можно я??? Спасибо!!!

А>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


Это очевидно.

Исторически DAL и прочие ORM появились как адекватный ответ на проблему типизированной работы с источником данных, точнее с отсутствием типизации. Некоторые решения остановились на минимально необходимом решении самой проблемы, некоторые пошли дальше, предлагая полную абстракцию от источника данных, используя в качестве такой абстракции объектную модель приложения. В результате мы имеем следующую модель взаимодействия: приложение <-> объектная модель <-> источник данных (включая его модель).

Linq позволяет решить исторически изначальную прооблему, а именно типизацию работы с источником данных. Как не трудно заметить, в этом случае объектная модель приложения, как средство типизированной работы с данными, оказывается абсолютно лишней. Более того вместе с ней уходят и присущие ей недостатки.

Нужна ли сама по себе объектная модель? Во многих случаях — да. Так, например, функционально богатое UI приложение может иметь свою объектную модель. Но как правило эта модель весьма сильно отличается от модели источника данных, т.к. предназначена для решения совсем других задач, никак не связанных с проблемами персистентности. Такие модели существовали задолго до появления ORM и никуда не делись с их появлением. Но объектная модель как заменитель источника данных больше не нужна. Более того, пытаясь быть и заменителем источника данных и объектной моделью приложения одновременно, такая модель делает хуже и то и другое, чем эти вещи по раздельности. Т.е. получается такая "объектная недомодель приложения совмещённая с недоисточником данных".

Во многих же приложениях, задача которых в основном сводится к выполнению разнообразных и малосвязанных между собой запросов, объектная модель приложения совсем не нужна. В них вполне достаточно модели данных.

Вывод таков — объектная модель, предлагаемая ORM по сути своей сегодня являет рудимент и атавизм, тупиковую ветвь прогресса. Думаю, что следующим на очереди будет переосмыслени функции DAL
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Взаимодействие с Базой Данных из C# по схеме MS
От: Аноним  
Дата: 08.09.08 09:01
Оценка: +3 -1
День добрый.

Заметил, что появился Linq и родственные технологии и активно продвигается. Как теперь канонично работать с базой данных (по стандарту, так сказать)?

1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?

2. Далее. Linq в какой-то степени заменяет SQL-запросы. Использовать ли теперь SQL-запросы или все делать через Linq? В каких случаях что использовать?

3. Если мне максимально быстро нужно сделать сайт с базой. Время запросов имеет не большой смысл -- главное быстро создать сайт. Значит ли это, что мне не нужно использовать ни хранимые процедуры, ни SQL-запросы и можно обойтись только Linq to SQL и Linq?

18.09.08 06:27: Перенесено модератором из '.NET' — TK
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: hamanu  
Дата: 08.09.08 09:34
Оценка: +4

А>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


Ошибаетесь. Это просто разные вещи.

А>2. Далее. Linq в какой-то степени заменяет SQL-запросы. Использовать ли теперь SQL-запросы или все делать через Linq? В каких случаях что использовать?


Вероятно, имеется в виду Linq2SQL. Если Вас устраивают те запросы, которые он генерирует, можете использовать.

А>3. Если мне максимально быстро нужно сделать сайт с базой. Время запросов имеет не большой смысл -- главное быстро создать сайт. Значит ли это, что мне не нужно использовать ни хранимые процедуры, ни SQL-запросы и можно обойтись только и Linq?


Можно обойтись. Linq to SQL как раз заточен под такие "быстрые" сценарии.
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 16.09.08 15:56
Оценка: +1 -2 :)
Здравствуйте, Sinclair, Вы писали:

S>Ну так вот его leakyness состоит в том, что на самом деле есть существенная разница между "здесь и сейчас" и "всё еще в базе". Функционально разницы нет. А вот с точки зрения производительности — разница есть. И когда я буду делать вызов order.Items[i].StockItem.Name, он легко приведет к отдельному запросу на каждой итерации.

Не приведёт. Стандартно для LL — загружать сразу всю коллекцию Items. Так что такой код будет работать вполне прилично.

У меня вообще ощущение, что если возникают проблемы с LL, то стоит посмотреть не делаем ли мы в коде слишком много лишних действий.
Sapienti sat!
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 29.09.08 03:07
Оценка: +4
Здравствуйте, Cyberax, Вы писали:
VD>>3. Полиморфизм.
C>Методы мы исключаем из рассмотрения.
Исключением существенных свойств ничего хорошего ты не получишь.
На всякий случай напомню, что центральная идея ООП — это инкапсуляция поведения. Структура объекту нужна только для обеспечения поведения, заявленного контрактом. Она непрозрачна; два разных объекта с одним контрактом имеют полное право иметь различную внутреннюю структуру.

Это полная противоположность РА, в которой всё обязано быть открыто. В классическом ООП вообще не имеет смысла говорить об "именах атрибутов класса", потому что они исключительно локальны. В РА не имеет смысл говорить о "поведении" кортежей, потому что всё возможное "поведение" описано операторами РА.

В ООП центральным понятием является идентичность объекта, благодаря которому мы можем иметь два различимых объекта в одинаковых состояниях. В РА кортежи полностью описываются своим состоянием и неразличимы.

Неопытному взгляду эти вещи кажутся несущественными — чего там, добавим во все отоношения колонку "ID", и получим идентичность. Но это плохая абстракция. Дело в том, что РА замкнута относительно своих операторов; что бы ты ни делал с отношениями, ты в результате получаешь новое отношение. Достигается этот замечательный эффект именно благодаря прозрачности данных. Но если ты попробуешь применять операторы РА к "отношениям с ID", ты будешь получать непонятно что. Этим результатам нет аналога в ООП. У них нет идентичности, инкапсуляции и полиморфизма.

Попытка построить непротиворечивую алгебру, скрестив РА с ООП, была предпринята в 1993 году. Сейчас, с учетом накопленного опыта, можно смело считать эту попытку проваленной. Оказалось, что даже если отвлечься от поведения (что, как я уже сказал, фактически эквивалентно отказу от ООП), оставив только идентичность и наследование реализации, то получившаяся математика не допускает эффективной реализации. Ну и мозг программиста успешно взрывается из-за того, что появляется слишком много вторичных типов данных. Простейшие вопросы, например эквивалентность отношения из (Name, Age) и отношения (User[Name, Age]), оказываются нетривиальными.

Вот такая вот примерно идеология. Поэтому говорить о том, что "классы банально отображаются на кортежи" можно только от поверхностности, граничащей с некомпетентностью.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sergey T. Украина http://overstore.codeplex.com
Дата: 06.11.08 17:19
Оценка: 12 (2) +1
Здравствуйте, Sinclair, Вы писали:


S>Весь смысл lazy loading — в том, чтобы спрятать от его пользователя информацию о том, когда именно происходит загрузка данных. Если программист видит, где именно происходит loading, то LL облажался. LL делает вид, что order.Items уже здесь и сейчас, а на самом деле они все еще в базе, и будут запрошены только когда я начну итерироваться по Items.


S>Ну так вот его leakyness состоит в том, что на самом деле есть существенная разница между "здесь и сейчас" и "всё еще в базе". Функционально разницы нет. А вот с точки зрения производительности — разница есть. И когда я буду делать вызов order.Items(i).StockItem.Name, он легко приведет к отдельному запросу на каждой итерации. И протечка будет ровно в том, что это приведет к чудовищной производительности данного решения. Это 100% аналог проблемы с конкатенацией строк, которую приводит Спольски.


S>И все способы борьбы с вот этой вот протечкой — это фактически отказ от абстракции. Вместо того, чтобы наивно итерироваться по order.Items, я буду должен отдать специальный cache hint и заставить ORM всё-таки залоадить данные энергичным способом. То есть никакого Lazy load уже нет, уже есть "forced lazy load". Всё, это и был щасливый конец LL.


S>Понимание причин протекания абстракции "persistence ignorance" оставляю в качестве домашнего задания.


Sinclair, в одном с вами и, наверное, IB, спорить трудно: нельзя, используя ОРМ, совсем "забывать" о данных. Нельзя полностью абстрагироваться от базы данных как хранилища со своей спецификой. Нельзя — как нельзя базу данных представить полностью в абстракции только наборов записей — без индексов, хинтов и тому подобных тонкостей. Потому что результат обеих абстракций будет один: работать будет, но очень часто медленно.


Приведенный вами пример, если представить его в абстракции СУБД, будет выглядеть примерно следующим образом

select * from 
order 
inner join orderItems on ...
inner join stockItems on ... 

where order.id = @someId


Следует заметить, что убери из базы все индексы и ключи — запрос этот будет ненамного быстрее работать, чем приведенный выше лейзи лоад.
То есть, база данных сама не может обладать достаточной информацией для построения оптимального по производительности хранилища. Ей нужна дополнительная информация.

Проведите эту аналогию на ОРМ — и вы увидите, что ОРМ тоже нуждается в такой же дополнительной информации. Например, указания о том, что весь ордер нужно грузить одним запросом — таким, какой приведен выше. Тогда разница на взаимодействие с СУБД сведется до нуля по сравнению с прямым запросом через IDataReader, и останутся лишь затраты на маппинг и т.п.

В чем же квинтэссенция современных субд? В том, что они дают для работы одну главную абстракцию — таблицу. И декларативный язык к ней. Все остальное — представления, индексы, хранимые процедуры — это средства ускорения работы (плюс модульности, повторного использования и т.п. — но сейчас не об этом). Причем стремится все к тому, чтобы об средствах ускорения работы забыть, как о минувшем веке (пока не получается). Суть же в том, чтобы отделить декларативный язык запросов от средства ускорения этих же запросов.

Аналогично и ОРМ — да, по состоянию "на сейчас" можно запросто произвести код, который положит производительность на лопатки. Но суть то не в этом — суть в том, что ОРМ стремится к идеалу, той самой пресловутой persistence ignorance. Как и СУБД стремится к INDEX IGNORANCE, HINTS IGNORANCE и т.п.

Пока же мы видим, что СУБД подходят очень интеллектуально к вопросам производительности. ОРМ — подходят к вопросам производительности "заблаговременно" и жестко — то есть, можно указать, что ордер нужно грузить таким вот одним запросом с товарами и строками вместе. Потому что они чаще всего вместе используются.

Но уважаемые — цель ОРМ — это не дать замену СУБД. Это дать возможность работать в смешанном императивно-декларативно (с выходом ЛИНК)-функциональном стиле. Это разделить гибко два уровня: хранение и обработка данных + обработка объектов с минимальными усилиями. Дать возможность в полную мощь развернутся императивному стилю, и при этом не потерять выгоду от декларативного.
There is no such thing as the perfect design.
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 17.09.08 09:45
Оценка: 6 (1) +2
Здравствуйте, Sinclair, Вы писали:

C>>LL тоже даёт тебе функциональное преимущество — возможность писать persistent-unaware код.

S>Это преимущества совершенно разного рода. Контроль размеров спасает меня от ошибки.
S>От какой ошибки спасает меня возможность писать persistent-unaware код?
От ошибки: "утащу-ка я всё в ХП".

S>Я в очередной раз говорю о том, что абстракция LL — leaky. Не надо ее сравнивать с

Hint: ВСЕ абстракции в какой-то мере leaky. Вопрос в том, перевешивают ли преимущества абстракции её текучесть.

C>>Может быть, логика в процессе разработки поменялась, или ещё что-нибудь. Не все же делают странички, просто показывающие результат одного запроса.

S>Ну поменялась — мы начали загружать другие данные. В чем проблема?
Так менять надо. Особенно замечательно, если получение данных и их отображение достаточно отделены. Или если получением данных занимается какой-то общий сервис.

S>А по факту он используется для "неперсистентных графов"?

Да. В основном, на графах объектов, полученных в виде XML от автономных узлов у клиентов, или на "толстом" GUI-клиенте.

C>>Конечно, можно было бы написать тонкий фильтр в виде хранимки, но тогда пришлось бы поддерживать два варианта кода — в этой хранимке, и на Java.

S>Нет, я не предлагаю опускать такую логику в СУБД. Я всего лишь не понимаю, какое место здесь занимает Lazy Load.
Ситуация — человек хочет взять отгул на какой-то день. Мне для принятия решения нужно: контракт этого человека, контракт с агенством, предоставившим этого человека, историю этого человека, статус в профсоюзе, наличие замены этому человеку и т.п.

Один только список inner join'ов будет на страницу, если сразу все данные подгружать. Причём вполне вероятно, что почти все эти данные не потребуются, если первое же правило даст отрицательный результат.

Да, и на практике почти все необходимые данные (контракты между кадровым агенством и заказчиком, профсоюзные данные и т.п.) будут висеть в кэше. Следовательно, обращение к ним будет на порядки быстрее запроса к БД.

S>На первом этапе — нет. На втором оказывается, что поднимать StoreItem со всеми его потрохами только для того, чтобы показать его Name в составе Order Item — слишом дорого. В итоге делают двухуровневый прокси: StoreItem режут на StoreItemName и StoreItemFull. И всё это потому, что полноценная ORM предлагает жесткую схему объектов.

Жжжуть. Во-первых, можно сделать lazy loading для отдельных полей (Hibernate это умеет). Во-вторых, так я бы точно не делал.

C>>Ты забыл только упомянуть, что классический SQL — он не Turing-complete. ОЧЕНЬ не Turing-complete.

S>Классический SQL — вообще в некотором роде фикция, т.к. он опирается на скалярные функции, набор которых — implementation-specific. А вообще, вроде бы должен быть turing-complete. Ведь достаточно иметь ноль, инкремент, и выбор N-го аргумента
SQL тогда должен быть достаточно мощным, чтобы соревноваться с Java/C#.

C>>Если не нравятся длинные пути — просто переходишь на реляционный стиль. В этом и сила ORM.

S>Ну-ну. И как этот реляционный стиль дружит с транзакциями и кэшем?
Нормально дружит. Какие тут проблемы?

S>
S>from OrderItem i in Connection.OrderItems 
S>    join StoreItem si on i.StoreItemID equals si.ID
S>    select si.Name, i.Quantity
S>

S>Прямо не знаю, сколько нужно ручной работы .
А теперь, пожалуйста, для всех OrderItem'ов, которые находятся в wishlist'е пользователя покажи мне их подробные детали.

Потом детали показать ещё для всех item'ов, помеченных количеством звёзд, выше порога, указанного в профиле пользователя.

C>>Про бОльшее количество деталей, за которыми надо следить.

S>Странно. Деталей меньше в LWORM, а следить приходится больше .
Так не приходится

S>Это всё обсуждалось позавчера. Извини, у меня уже терпения не хватает, чтобы объяснять каждому из вас, что я думаю про решения созданных самими же себе проблем. Потому что дальше мы будем обсуждать, как замечательно проблемы когерентности распухшего кэша решаются при помощи очередной "грубой силы".

Локальная когерентность кэша решается интеграцией его в ORM. Межузловая когерентность — с помощью кластерных кэшей. Руками его делать — это да, полная дупа.

В том же Hibernate в Java подключение кэша сводится к нескольким строкам в конфиге, и он даже будет в дефолтной конфигурации работать почти для всех случаев.
Sapienti sat!
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 09.09.08 05:59
Оценка: 2 (2) +1
Здравствуйте, IB, Вы писали:

IB>Зачем использовать две сторонние библиотеки сомнительного качества, когда можно использовать одну, которая идет вместе со студией?


К большому сожалению linq2sql поддерживает только одну СУБД.

А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 17.09.08 09:07
Оценка: 2 (1) -1 :)
Здравствуйте, Cyberax, Вы писали:

C>То есть?

То есть — у тебя все в перемешку, тут LL, а тут надо явно загрузить, потому что LL не справляется, а тут LL сегодня справляется, а завтра нет...

C>А потом по связям этих объектов пройтись, с использованием LL.

Зачем проходиться по связям LL, если можно сразу все загрузить явно? Это проще в реализации, проще в поддержке, очевиднее и прозрачнее. Зачем иметь на свою голову геморрой в виде LL, который не известно когда стрельнет?

C>Да. И что из этого?

Из этого следует, что лучше сразу додумать.

C> С LL ситуация абсолютно аналогичная.

Ничего подобного. Спроектировать приложение сразу без использования LL дешевле, чем потом бороться с его последствиями.

C>ORM реально позволяет сократить затраты по времени разработки, так что всё нормально. И использовать ORM совсем несложно.

Использование мапперов типа linq-а и BLT сокращает время разработки ровно на столько же, если не больше, только код получается более очевидный и легко поддерживаемый.

C>Ну а что по-твоему делает LL?

Замазывает проблему, вметсо ее решения.

C>>>В том-то и дело, что справляются хуже.

IB>>Чем?
C>Сложнее использовать в коде, который ориентирован на объектный стиль использования данных.
Так вот я и говорю, что использовать данные объектно — это натягивать на глобус презерватив. Если данные изначально реляционные, то не надо их насиловать, проще понятнее и надежнее использовать их так как они есть.
Иными словами, весь функционал направленый на то, чтобы использовать данные объектно — не нужен, потому тчо данные нужно использовать не объектно.

C>LINQ — он для выбора данных. Ну получишь ты массив анонимных туплов. Что дальше делать с ними?

Во-первых, не обязательно анонимных, а во-вторых — передам в сервис, который знает что с ними делать.

C>Ну не половину, просто некоторые баги в тёмных углах там пофиксил. Оказалось быстрее, чем переписывать всё с нуля.

Конечно быстрее. После того как ты угробил кучу времени разбираясь с гибернейтом, естественно оказалось быстрее довести дело до конца, чем все бросать... =)
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.09.08 11:20
Оценка: 1 (1) +1 -1
Здравствуйте, <Аноним>, Вы писали:

А>Заметил, что появился Linq и родственные технологии и активно продвигается. Как теперь канонично работать с базой данных (по стандарту, так сказать)?


Нет такого стандарта в прироже. И не будет.

А>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь?


Ошибаешься.

А> Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


Нет.

А>2. Далее. Linq в какой-то степени заменяет SQL-запросы. Использовать ли теперь SQL-запросы или все делать через Linq?


Если уж LINQ в проекте применяется — лучше только через него.

А> В каких случаях что использовать?


Это очень многофакторный вопрос.

А>3. Если мне максимально быстро нужно сделать сайт с базой. Время запросов имеет не большой смысл -- главное быстро создать сайт. Значит ли это, что мне не нужно использовать ни хранимые процедуры, ни SQL-запросы и можно обойтись только Linq to SQL и Linq?


Нет, не значит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 08.09.08 15:57
Оценка: +2 -1
Здравствуйте, kuj, Вы писали:

kuj>Поясни.

Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.

kuj>Нет.

Ну ладно, нет в том виде, в котором это привыкли видеть в NHibernate, что тоже плюс.

kuj>Работать с транзакциями? Таки нужно.

Работать с транзакциями вне контекста — не нужно.

kuj>И что же там такого непростого?

Все в нем не просто и местами довольно криво.

kuj>С использованием ActiveRecord все вообще элементарно.

Угу, вот обертку над оберткой использовать — вообще отличная идея.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 09.09.08 08:12
Оценка: -1 :))
Здравствуйте, Ziaw, Вы писали:

Z>К большому сожалению linq2sql поддерживает только одну СУБД.

А зачем больше?

Z>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.

Помоему очевидно, что одна библиотека, которая решает конкретную задачу, конкретным способом, будет заведомо качественнее двух библиотек от разных производителей, одна из которых порывается делать все, включая приготовление кофе по расписанию. Разьве нет?
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 09.09.08 08:17
Оценка: -2 :)
Здравствуйте, IB, Вы писали:

Z>>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.

IB>Помоему очевидно, что одна библиотека, которая решает конкретную задачу, конкретным способом, будет заведомо качественнее двух библиотек от разных производителей, одна из которых порывается делать все, включая приготовление кофе по расписанию. Разьве нет?

Нет.
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: mashot  
Дата: 15.09.08 20:35
Оценка: -1 :))
Здравствуйте, Аноним, Вы писали:

А>День добрый.


А>Заметил, что появился Linq и родственные технологии и активно продвигается. Как теперь канонично работать с базой данных (по стандарту, так сказать)?


А>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


А>2. Далее. Linq в какой-то степени заменяет SQL-запросы. Использовать ли теперь SQL-запросы или все делать через Linq? В каких случаях что использовать?


А>3. Если мне максимально быстро нужно сделать сайт с базой. Время запросов имеет не большой смысл -- главное быстро создать сайт. Значит ли это, что мне не нужно использовать ни хранимые процедуры, ни SQL-запросы и можно обойтись только Linq to SQL и Linq?


Скорее всего — это не стандарт, а определенная нотация кода.
1)Последний гвоздь в крышку гроба NHibernate забил Ado.Net Entity Framework.
Уже скачал и поставил — просто чудо. Релиз вместе с VS 2008 SP1 вышел.
и теперь конечно исп-е NHibernate ставится под сомнение.
2)Если нужна высокая производительность, ну прям действительно важен
выйгрыш в 10% или более, то конечно исп-ся IDataReader в паре со
строковыми запросами на SQL,
ну а ежели нет, тогда зачем мучится — Linq to SQL и все ОК.
3)Конечно можно обойтись Linq to SQL.
(Там очень интересная модель выполнения и построения запросов,
чем впринципе так сильно отличается Linq to SQL от Linq to Objects и Linq to ...)
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.09.08 08:56
Оценка: +2 -1
Здравствуйте, Cyberax, Вы писали:

C>LL тоже даёт тебе функциональное преимущество — возможность писать persistent-unaware код.

Это преимущества совершенно разного рода. Контроль размеров спасает меня от ошибки.
От какой ошибки спасает меня возможность писать persistent-unaware код?
Я в очередной раз говорю о том, что абстракция LL — leaky. Не надо ее сравнивать с


C>Может быть, логика в процессе разработки поменялась, или ещё что-нибудь. Не все же делают странички, просто показывающие результат одного запроса.

Ну поменялась — мы начали загружать другие данные. В чем проблема?

C>Именно. Причём с меньшим числом ручных теложвижений.

Непонятно про меньше телодвижений.

C>Получение данных тоже разное бывает.

И?

C>Объём кода получится НЕ тот же самый. Хотя бы из-за того, что с LL можно оставить некоторые неявные зависимости на совести самой ORM, и не прописывать их явно в запросах.


C>Моё решение — берём все объекты с помощью грубого фильтра (наличие цепочки переходов до состояния "C", не считая ACL). А потом эти объекты отдельно уже профильтровать тонким фильтром. Так вот этот тонкий фильтр написан так, что он не знает что-либо о персистентности объектов, так что он может использоваться и в контексте неперсистентных графов объектов в памяти.

А по факту он используется для "неперсистентных графов"?
C>Конечно, можно было бы написать тонкий фильтр в виде хранимки, но тогда пришлось бы поддерживать два варианта кода — в этой хранимке, и на Java.
Нет, я не предлагаю опускать такую логику в СУБД. Я всего лишь не понимаю, какое место здесь занимает Lazy Load.

S>>Правда что ли? А введение "недозаполненных" прокси-классов для оптимизации выборок в ORM не превращает схему маппинга в Ктулху?

C>Нет. С чего бы? Lazy loading не влияет на схему саму по себе.
На первом этапе — нет. На втором оказывается, что поднимать StoreItem со всеми его потрохами только для того, чтобы показать его Name в составе Order Item — слишом дорого. В итоге делают двухуровневый прокси: StoreItem режут на StoreItemName и StoreItemFull. И всё это потому, что полноценная ORM предлагает жесткую схему объектов.

C>>>От объектного подхода нам нужны графы объектов, которые ведут себя как графы объектов.

S>>Вот тут опять непонятно. Лично меня всегда напрягало, что для разных юзкейзов нужны разные графы объектов. Вот в РСУБД с этим все очень хорошо: кодд выполнил домашнее задание по реляционной алгебре. Я конструирую нужную реляцию, а сервер обеспечивает мне ее выполнение.
C>Ты забыл только упомянуть, что классический SQL — он не Turing-complete. ОЧЕНЬ не Turing-complete.
Классический SQL — вообще в некотором роде фикция, т.к. он опирается на скалярные функции, набор которых — implementation-specific. А вообще, вроде бы должен быть turing-complete. Ведь достаточно иметь ноль, инкремент, и выбор N-го аргумента

C>Если не нравятся длинные пути — просто переходишь на реляционный стиль. В этом и сила ORM.

Ну-ну. И как этот реляционный стиль дружит с транзакциями и кэшем?

C>Отдельно заниматься mapping'ом результатов каждого запроса или загрузкой всего необходимого.

О да, это ж прямо ужас как приходится напрягаться, чтобы отмапить
from OrderItem i in Connection.OrderItems 
    join StoreItem si on i.StoreItemID equals si.ID
    select si.Name, i.Quantity

Прямо не знаю, сколько нужно ручной работы .
В BLToolkit, конечно, есть где разогнаться. Там придется для OrderLine писать класс. Зато не нужен класс для OrderItem, если он не используется.
C>Про бОльшее количество деталей, за которыми надо следить.
Странно. Деталей меньше в LWORM, а следить приходится больше .
C>Часто проблема Lazy Loading'а замечательно решается применением "грубой силы" — кэшем объектов в памяти. Чем-то напоминает ситуацию в процессоростроении.
Это всё обсуждалось позавчера. Извини, у меня уже терпения не хватает, чтобы объяснять каждому из вас, что я думаю про решения созданных самими же себе проблем. Потому что дальше мы будем обсуждать, как замечательно проблемы когерентности распухшего кэша решаются при помощи очередной "грубой силы".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: Аноним  
Дата: 17.09.08 09:02
Оценка: +3
Здравствуйте, WaSh, Вы писали:

WS>Вот так безобидный вопрос..... вырос в священные войны...


для кого войны, а для кого очень хороший источник информации о в общем-то проблемном вопросе. мне, например, интересно читать такие разные точки зрения, + по ходу дела всплывают не совсем относящиеся к теме, но не менее важные вопросы.

поэтому продолжайте господа, вас приятно слушать!
Re[7]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 20.09.08 01:46
Оценка: +3
Здравствуйте, Cyberax, Вы писали:

IB>>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.

C>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.11.08 23:35
Оценка: +1 :))
Здравствуйте, Cyberax, Вы писали:

C>ObjectSpaces — это был очень примитивный фреймворк.


Это очень хороший фреймворк. Патамуша мертвый

C> Интересно, а его команда в развитии EF участвовала?


Да. Выдающаяся по количеству убитых проектов команда (WinFS тоже на их груди сияет, если что). Я вот уже думал, что наконец то один успешный проект появился — linq2sql. Ан нет, они и его похоронили. И EF они тоже похоронят, не сомневайся Неудачники

C>Вообще, хороший ORM-фреймворк — это весьма сложная штука.


В этом и проблема.

C> Слишком многое можно сделать неправильно.


А самое главное, даже когда сделаешь — все одно непонятно, правильно оно или нет. Тестирую то все больше на игрушечных сценариях, когда много редактирования и мало массовых операций, и никаких тебе интерпрайз заморочек.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 03.12.08 00:27
Оценка: 22 (2)
Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, Gaperton, Вы писали:


G>> Посмотри, как устроено 1С:Предприятие 8, модуль торговля+склад или как он там называется. Там вся база делается на трех классах объектов — справочник (статический объект), документ (соответствует действию, имеет время и может двигать "регистры"), "регистр" (похоже на OLAP-звезду, по нему можно строить отчеты и снимать с него в реальном времени, скажем, остатки).

A>Занятно. Спасибо, посмотрю.
A>...
A>Залез в Гугл -- инет забит рекламой. Если не сложно (в пределах 2-х, 3-х кликов), можно ли меня "ткнуть носом" описание?

Боюсь, что нет. Во-первых, я этим прекратил заниматься в 2000 году, еще на версии 7.7, и сейчас уже не в теме. Во-вторых, тогда вообще не было никаких учебников, приходилось учится это готовить самим. Сейчас, вероятно, должны уже появиться какие-то книги.

Я тебя предупреждаю — это реально путь для мазохистов, если тебе не удастся найти толковой книги. Документация 1С тогда отдельно от их коробок не продавалась, и всегда была тошнотворным отстоем, вызывающим у программеров стойкий рвотный рефлекс.

Вообще, все очень просто. Система построена на нескольких простых принципах — рассказываю про 7.7.
1) Система состоит из объектов трех разных видов, которые представляют собой персистентные объекты. Справочники, Документы, и Регистры.
2) Справочники и Документы имеют визуальные формы, и могут редактироваться пользователем при их помощи.
3) Регистры являются почти классической OLAP-звездой, с тем исключением, что позволяют моментально брать остатки на текущий момент.
4) Справочник — это простая тупая таблица. Почти. Потому, что в ней может быть деревянная структура элементов. Можно задавать формы для просмотра всего справочника, и редактирования элементов. Поля элементов справочника могут ссылаться на объекты, которые лежат в других справочниках.
5) Система целиком берет на себя вопросы персистенса и data binding, и сама отслеживает вопросы редактирования полей объектов в формах, полагаясь на их типы. Например, при попытке редактирования поля типа справочник, она сама вывалит указанную форму списка для нужного "справочника".
6) Справочники моделируют статические объекты. А Документы — это объекты, которые моделируют действие. У документов обязательно есть дата и время. Документы могут быть "проведены", то есть изменять "регистры".
7) База данных 1С не только объектна, но и темпоральна. Время присутствует в ней в явном виде. Его можно двигать назад, и тогда все изменения в регистрах, сделанные документами за период отката, будут отменены. А можно — вперед, и тогда документы опять выполнят "проведение", возможно — с новым, исправленным алгоритмом. Это позволяет полностью менять всю аналитику на рабочей базе, выпоняя любые манипуляции с регистрами и учетными алгоритмами.
8) Регистры нужны для построения отчетов. Хорошая практика — если для отчета не хватает регистров, добавь новые, или расширь старые, воспользовавшись "темпоральностью", но не строй отчеты по "документам", как это принято в реляционных БД. Регистры избыточны, и всегда полностью восстанавливаются проведением документов. Польза в них, кроме производительности — они делают аналитику и учет полностью независимой от бизнес-процессов, этот механизм — своего рода слой абстракции.
9) Регистр содержит "измерения", которые могут быть любых типов, в том числе документ и справочник, и эти, как их "ресурсы", которые есть только числовые поля. В ацком языке запросов 1С, у которых есть параметр "период" (диапазон дат) на ресурсах регистра доступны магические темпоральные агрегатные функции, такие как "расход" и "приход". Пример регистра — "остатки товаров". Измерения: Товар, Склад. Ресурсы: КолВо, Стоимость. Документ при проведении делает в регистр запись вида "прибавить к ресурсам такие-то числа, при значениях измерений таких-то".
10) Отчет — это тупо визуальная форма, для ввода параметров отчета, печатная форма, напоминающая Excel, и программный код, который строит отчет. То есть — это не объект, а так.

Примерно все. Понятно, как работает?
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 21.09.08 17:28
Оценка: 5 (2)
Здравствуйте, IT, Вы писали:

IB>>>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.

C>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

IT>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.


Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google. Это уже в ближайшие годы станет популярной и очень серьезной альтернативой RDB, особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают. Сейчас — они поднимаются по хайпу, скоро будут на пике.

Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее, практически весь геморрой, знакомый по RDB, отсутствует by design. Сочетание чрезвычайной простоты, и одновременно — большой гибкости. Обрати внимание, там чрезвычайно простая модель, много времени не займет. За полчаса будешь знать все. И не надо мне говорить про то, что там все запросы делаются через REST, а это медленно . К модели данных это не относится, а CouchDB демонстрирует пока только потенциал технологии.
Re[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 08.09.08 11:24
Оценка: +2
Здравствуйте, Аноним, Вы писали:


kuj>>Linq не является ORM. Linq это просто язык запросов. Кстати, есть Linq to NHibernate.


А>Имелось в виду Linq2Sql, конечно... А он несомненно является намного более удобным и простым в использовании ORM. Так что думаю гвоздь все-таки забил? Что скажете?


Скажу что Вы плохо понимаете то о чем говорите.
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 09.09.08 02:49
Оценка: -1 :)
Здравствуйте, 0K, Вы писали:


kuj>>>>Поясни.

IB>>>Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.
kuj>>Linq2sql не является ORM, как я уже упоминал.

0K>Т.е. вы имеете в виду полноценной ORM? Т.к. если придерживатся понятий, то очень даже является: wiki/ORM


ОО — полиморфизм, инкапсуляция, наследование.
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 16.09.08 10:56
Оценка: -2
Здравствуйте, Sinclair, Вы писали:

C>>Спасибо я знаю что такое leaky abstractions.

S>Непохоже.
Вы считаете, что Вы знаете что такое leaky abstractions? Не похоже. Вот именно.
C>> В любой архитектуре могут появиться leaky abstractions.
S>Абстракции в архитектуре есть всегда. Вообще вся архитектура — это выбор абстракций. Ты имел в виду, что любая абстракция может стать leaky?
Конечно.
C>>Единственная leaky abstraction в NHibernate это возможность использования SQL напрямую. Честно говоря, даже не знаю зачем ее оставили. На моей практике ни разу не потребовалось прибегать к ней.
S>Непохоже, что ты понимаешь, что такое leaky abstraction. Тебе понятно, почему lazy loading и persistence ignorance — leaky? Если непонятно, то что именно?
Вы это серьезно? Ну и фантазия у Вас...
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 16.09.08 14:32
Оценка: -1 :)
Здравствуйте, criosray, Вы писали:

C>Я Вас кажется не оскорблял.

Ты просто не заметил...

C>Во-вторых, то, что пишите Вы не имеет ничего общего с leaky abstractions.

То что у тебя с терминологией бедулька — уже давно понятно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: WaSh http://kxlm.blogspot.com/
Дата: 17.09.08 05:50
Оценка: :))
Вот так безобидный вопрос..... вырос в священные войны...
... << RSDN@Home 1.2.0 alpha 4 rev. 1108>>
блог http://kxlm.blogspot.com/
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 17.09.08 06:52
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

C>>Опять абсолюты. На практике (лично мне), например, очень часто удобно запросом выделить нужные объекты и работать с ними. LL работает тут как удобный "парашют" для тех случаев, когда нужно взять несколько незагруженных объектов.

S>Это очень дорогой парашют. Лично мне он больше напоминает мышеловку.
Ты жалуешься на то, что .NET в обязательном порядке проверяет индексы массивов? А ведь то же самое, по сути — замедление в некоторых случаях может быть очень заметным по сравнению с нативным кодом.

S>Что значит "когда она mature"? Я вижу два варианта трактовки "LL optimization maturity":

S>1. Мы наконец поняли, какие объекты мы трогаем в рамках часто используемых use-case, и специальными хинтами вынуждаем ORM выполнить раннюю загрузку
Да, именно этот сценарий и есть mature. Вдобавок, тут надо ещё добавить, что нас интересуют не все наиболее часто используемые use-case'ы, а только самые тормозящие.

Их обычно совсем немного, это скорее всего будут какие-то выборки, работающие с большим числом элементов. А методы типа add_order/remove_order/assign_product_to_order будут прекрасно работать что с LL, что без него. Так как разница между одной SQL-командой или, скажем, тремя — ничтожна, если они вызываются всего несколько раз в секунду.

S>В итоге, мы имеем отсутствие LL на основных путях работы системы (и наш код эквивалентен загрузке датасетов с точностью до синтаксиса), и всё еще неприлично тормозную реализацию редких юз-кейзов.

На нагруженных путях ещё может быть и оптимизированный ручной SQL и специальная обработка запросов. На то они и нагруженные пути.

Зато при этом за счёт того, что в редких use-case'ах не надо заниматься premature-оптимизацией, имеем выигрыш в общем времени разработки.

C>>Кстати, возможны и ситуации, когда LL экономит время. Например, если нам достоверно известно, что в ходе выполнения метода понадобится подгрузить всего несколько объектов. Но невозможно заранее сказать каких.

S>Не понял. Где экономия-то? Если нам невозможно сказать заранее, каких объектов, то мы просто будем вынуждены их загружать.
Ну да, в виде отдельных запросов, с поведением изоморфным LL.

S>А вообще, ситуация "невозможности заранее" в некотором смысле искусственная. Это опять про девиации сознания, вызванные инструментом.

Необязательно. Например, у меня есть условия, которые в SQL записываются в виде килобайтного кода.

S>Поясню тезис: когда приложение проектирует программист-реляционщик, он всё время мыслит в терминах РСУБД и запросов. Когда ему нужно отбирать объекты по сложному критерию, он сразу думает о дополнительном поле (возможно, вычисляемом). Если ему нужно выводить произвольно отсортированный список, он придумает дополнительное поле "порядок для вывода".

И это очень быстро превращает схему БД в некий аналог Ктулху.

S>Вблизи всё выглядит правильно: как же еще обходить список, кроме как при помощи LL? Чуть подальше всё выглядит по-другому: список — противоестественная конструкция для БД, именно потому, что невозможно заранее сказать, что загружать. Приложение должно быть спроектировано так, чтобы заранее можно было сказать, что загружать. Это инженерная задача.

Список — это вообще последнее дело. Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

C>>В том-то и дело, что справляются хуже. На практике нужна смесь реляционного и объектного подхода.

S>А что именно от объектного подхода нам нужно? Не могут ли это обеспечить lightwaight ORM?
От объектного подхода нам нужны графы объектов, которые ведут себя как графы объектов.

Lightweight ORM я лично пробовал, и может кому-то и нравится возиться с ними, оптимизируя каждый уголок. Но мне они просто не приносили существенной выгоды при увеличении объёмов ручной работы (читать: "мест для ошибок").

Идеально подошли бы гибридные OODB+RDB, но нет их сейчас нормально на рынке, что тут сделать.

C>>Все мои приложения под этот класс подходят. Обычно на ORM прекрасно пишется 95% кода, с остальными 5% в виде ручного SQL.

S>А мы в общаге 95% еды ели алюминиевыми ложками. Потому что вилка была всего одна
Я вот 90% еды сейчас палочками ем. Это удобнее, чем вилка!

S>На что похожи все предметы, когда у тебя молоток?

Т.е. lightweight ORM?
Sapienti sat!
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 17.09.08 08:12
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>Во-вторых, проверка индексов дает мне функциональное преимущество. Это понятно? А LL дает мне всего лишь повязку на глаза, чтобы я не видел, когда данные будут загружены.

LL тоже даёт тебе функциональное преимущество — возможность писать persistent-unaware код.

C>>Да, именно этот сценарий и есть mature.

S>Отлично. А что нам мешало понять сразу, какие объекты нам нужны? Резервирование товара — не rocket science; всё равно мы придем к тому же самому, только в профиль.
Может быть, логика в процессе разработки поменялась, или ещё что-нибудь. Не все же делают странички, просто показывающие результат одного запроса.

C>>Их обычно совсем немного, это скорее всего будут какие-то выборки, работающие с большим числом элементов. А методы типа add_order/remove_order/assign_product_to_order будут прекрасно работать что с LL, что без него.

S>В принципе да; атомарные изменения по ID объекта работают приемлемо, поскольку LL фактически делает ту же самую работу, что и eager load.
Именно. Причём с меньшим числом ручных теложвижений.

C>>На нагруженных путях ещё может быть и оптимизированный ручной SQL и специальная обработка запросов. На то они и нагруженные пути.

S>Непонятно, почему не начать с того, чтобы честно разделить фазу получения данных и фазу их обработки, вместо того, чтобы убеждаться, что система не работает.
Получение данных тоже разное бывает.

S>Непонятно, что тут есть оптимизация. Я же не предлагаю сразу начинать с оптимизированного вручную SQL. Я просто предлагаю писать код в другом стиле.

S>Объем кода получится тот же самый; поэтому неясно, за счет чего мы проиграем во времени разработки.
Объём кода получится НЕ тот же самый. Хотя бы из-за того, что с LL можно оставить некоторые неявные зависимости на совести самой ORM, и не прописывать их явно в запросах.

Например, у меня самое противное — часто логику придётся дублировать в SQL и в основном коде. Для меня достаточно частая ситуация — есть некая state-машина и объекты с состоянием, и нужно выбрать все объекты, для которых возможен переход в состояние "C" с учётом правил доступа текущего пользователя. На SQL это сделать проблематично, так как переходы между состояниями зависят от многих факторов.

Моё решение — берём все объекты с помощью грубого фильтра (наличие цепочки переходов до состояния "C", не считая ACL). А потом эти объекты отдельно уже профильтровать тонким фильтром. Так вот этот тонкий фильтр написан так, что он не знает что-либо о персистентности объектов, так что он может использоваться и в контексте неперсистентных графов объектов в памяти.

Конечно, можно было бы написать тонкий фильтр в виде хранимки, но тогда пришлось бы поддерживать два варианта кода — в этой хранимке, и на Java.

C>>Необязательно. Например, у меня есть условия, которые в SQL записываются в виде килобайтного кода.

S>Вот это интересно. Расскажи — попробуем отделить девиации от сознания.
См. выше.

C>>И это очень быстро превращает схему БД в некий аналог Ктулху.

S>Правда что ли? А введение "недозаполненных" прокси-классов для оптимизации выборок в ORM не превращает схему маппинга в Ктулху?
Нет. С чего бы? Lazy loading не влияет на схему саму по себе.

C>>От объектного подхода нам нужны графы объектов, которые ведут себя как графы объектов.

S>Вот тут опять непонятно. Лично меня всегда напрягало, что для разных юзкейзов нужны разные графы объектов. Вот в РСУБД с этим все очень хорошо: кодд выполнил домашнее задание по реляционной алгебре. Я конструирую нужную реляцию, а сервер обеспечивает мне ее выполнение.
Ты забыл только упомянуть, что классический SQL — он не Turing-complete. ОЧЕНЬ не Turing-complete.

S>Я никак не ограничен набором хранимых таблиц в своих манипуляциях. А ОРМ предполагает, что я придумаю некий единый граф объектов, и всю жизнь приложения буду с ним работать. Я не могу получить напрямую граф из префектов и студентов, я вынужден тащить объекты групп, которые их объединяют. И навигироваться вдоль этого графа. А если мне не нравятся длинные пути, то мне придется вручную прокладывать шорткаты и следить за их обновлением.

Если не нравятся длинные пути — просто переходишь на реляционный стиль. В этом и сила ORM.

C>>Lightweight ORM я лично пробовал, и может кому-то и нравится возиться с ними, оптимизируя каждый уголок.

S>Непонятно, что такое "оптимизировать каждый уголок"
Отдельно заниматься mapping'ом результатов каждого запроса или загрузкой всего необходимого.

C>> Но мне они просто не приносили существенной выгоды при увеличении объёмов ручной работы (читать: "мест для ошибок").

S>Непонятно, откуда увеличение объемов ручной работы. Это ты про написание самодельного кэша и LL?
Про бОльшее количество деталей, за которыми надо следить.

C>>Идеально подошли бы гибридные OODB+RDB, но нет их сейчас нормально на рынке, что тут сделать.

S>Ты знаешь, я даже в ООДБ как-то сомневаюсь. Точнее, я пока вижу мало способов существенно улучшить нынешнюю ситуацию путем внедрения ООДБ. Так, чтобы это не превратилось в плохую копию РДБ. Я бы понял, если бы удалось получить нормальную компонентную модель.
Часто проблема Lazy Loading'а замечательно решается применением "грубой силы" — кэшем объектов в памяти. Чем-то напоминает ситуацию в процессоростроении.

C>>Я вот 90% еды сейчас палочками ем. Это удобнее, чем вилка!

S>Открой для себя прелесть борща
А это как раз почти все остальные 10% (очень люблю окрошку)
Sapienti sat!
Re[5]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 19.09.08 15:00
Оценка: +1 -1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>По твоему объектаная модель может быть только в C#?


Ты о чём? Посмотри на название темы.

IT>>тебе домашнее задание — найти связь между типизацией и объектной моделью


ANS>нельзя найти то, чего нет


Или то, чего в упор не хочешь видеть. Или видишь, но очень хочется поспорить и единственный шанс — это свести всё к терминологической грызне.

ANS>ORM появились появились еще в Smalltalk, где проверка типизированности данных не требование. А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными. Т.е. конвертация данных в объектную модель — цель существования ORM.


Всё когда-то появилось. Лямбды появились ещё в лиспе, а в мэйнстрим попали только сегодня. Не прошло и 50-ти лет. У современных ORM, которые узурпировали этот термин в сегодняшнем его понимании, довольно незатейливая история развития, которой пока ещё не более 10 лет. Не важно когда впервые появился этот термин, главное что им теперь обзывают. На самом деле ORM вообще сегодня не отражает полностью суть того, чего им именуют. А ты тут про Smalltalk вспоминаешь
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 20.09.08 23:09
Оценка: -2
Здравствуйте, IT, Вы писали:

C>>Существуют: разные OODB, для мелких БД — Prevayler.

IT>То что они существуют совершенно не означает, что это альтернатива.
RDB сейчас выигрывают только за счёт удобных инструментов и навороченности самих баз. Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

Просто так получилось.
Sapienti sat!
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 24.09.08 10:54
Оценка: +2
Здравствуйте, mogadanez, Вы писали:

M>Это не так.

Хм.. Ну я вот, будучи практикующим разработчиком, чужой код не враз вкурю, а просто заказчик со стороны... Меня терзают смутные сомненья.

M>скорее DSL, на крайний случай fluent-interface.

Так ведь SQL существенно больше DSL напоминает, чем императивный шарп.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 29.09.08 02:50
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

C>Ну давай смотреть. В Вики перечислены следующие свойства реляционной алгебры:

C>1) Проекция, выборка, фильтрование, переименование — всё есть в прямом виде.
C>2) Объединения: натуральный джойн, тэта-джойн, outer left/right, inner join — всё тоже есть.
Да? И где в SQL натуральный джойн? Где семи-джойн? Где деление? Где антиджойн?

C>В итоге, SQL прекрасно представляет реляционную алгебру.


Ее можно эмулировать на SQL без особых проблем. Тем не менее, SQL достаточно сильно отличается от "классической" РА, и именно потому, что "инженерные" соображения оказались важнее, чем 100% соответствие.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.09.08 07:05
Оценка: 58 (1)
Здравствуйте, Cyberax, Вы писали:

C>То что ты рассказывал как у вас там всё работает — это чистый антипаттерн использования Hibernate. У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.


Ты думаешь это от хорошей жизни так сделали? У каждого потока есть своя сессия, как полагается. Только скорость обработки запроса была упала в 6 раз по сравнению с без гибернейта в лучшем случае, до совершенно несуразных цифр там, где доля работы с БД была побольше. И потребление памяти на некоторых задачах подскочило с 2-х гиг до 16 (большой привет каждому треду со своим графом объектов).
Естественно, это проблема не ORM вообще, а проблема неоптимальности конкретного Hibernate. Проблема ORM в невозможности без проблем работу распаралелить или закешировать. Попытки что-то закешировать приводили поначалу к слабоуловимым ошибкамт(совершенно разным и феерическим), а теперь привела к необходимости превентивно резолвить все LL ссылки. Т.е. на всякий случай приходится грузить дерево объектов, потому что не ясно какой кусок, когда и кому понадобится.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 01:10
Оценка: 10 (1)
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Gaperton, Вы писали:


G>>Я тебе чисто, как настоящий сварщик своему коллеге, скажу в ответ вот что. Вступление.

IB>А я, типа, только каску держал?

G>>Лет 10 назад мы с друзьями занимались корпоративными приложениями на базе RDBMS, и были рьяниыми сторонниками нормализации и многоуровневых архитектур.

IB>Нормализация тут непричем. Реляционка хороша тем, что связи там протаптываются с другого конца, чем в OO, в следствии чего любая иерархия строится по месту, а не прибивается гвоздями на этапе проектирования. И такой способ работы с данными удобнее, так как иерархия объектов сильно зависит от конкретного юзкейса и вообще имеет тенденцию эволюционировтаь в процессе эксплуатации приложения и изменениия требований.

Как говорил один мой знакомый — "да, и нет".

У тебя все равно юзкейсы делятся на два класса. 1 — "гуевые" кейсы, которые связанны со вводом информации и OLAP. Эти кейсы отлично кладутся на "расширенную реляционную модель" — где у тебя вместо кортежей тегированные деревья.

И вторая группа кейсов связанна с аналитикой — так не надо аналитику по "документам" строить . Заводишь ROLAP-звезды, и строишь отчеты по ним. Каждый "документ" (объект, соответствующий действию) создает при записи движение в нужных звездах. При этом, у тебя аналитика получается развязана с оперативным учетом — связь происходит посредством описания операций "проведения документов". И все.

Поэтому, на практике при таком подходе получается, что тебе чаще всего просто не нужна способность реляционной модели натягивать иерархию с любой точки. Ты платишь за это избыточностью информации, примерно двукратной. Зато приобретаешь очень интересные полезные свойства. Например, у тебя элементарно все быстрее работает, за счет того, что join-ов стало меньше.
Re[2]: По итогам дискусии напрашивается вопрос
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 01.10.08 03:04
Оценка: 8 (1)
Здравствуйте, Константин Л., Вы писали:

КЛ>1. orm почти всегда плохо

Смотря какой ORM. В ветке интенсивно обсуждались Full-blown ORM versus Lightweight ORM.
В ORM плохо не всё, а только

а) Lazy Load
б) Navigational Access
в) Overcaching

КЛ>2. 3-tier хорошо, тк не нагружаем сиквел etc.

Ненагруженность сиквела — не главное. Вообще, с точки зрения нагрузки, есть следующие факторы:
1. Кэширование. Кэш сиквела построен на очень низком уровне, он близок к дисковому кэшу. Из-за этого, к примеру, cache cost для "горизонтального" запроса (где строк в результате мало, но они джойнятся из широкого набора таблиц) значительно выше, чем стоимость кэширования готового результата запроса в среде с более выразительной семантикой.
2. Сам язык. Производительность большинства диалектов SQL для процедурно-императивного кода ниже всякой критики, сравниваясь с характеристиками доисторических интерпретаторов.
3. Ограничения набора декларативных операторов. Реальные приложения зачастую работают с более сильными ограничениями, чем предлагает RDBMS, но сказать об этом приложение (в рамках SQL) не может. К примеру, если мы используем таблицу как очередь, то схема блокировок, принятая в generic RDBMS будет не самой эффективной.

Проблема номер два в современных коммерческих DBMS практически решена за счет возможности исполнять не-SQL код. В Оракле много лет можно исполнять джаву, в MS SQL с 2005 можно исполнять .Net код; а платформенно-зависимые расширенные хранимые процедуры поддерживают вообще, по-моему, все.

Проблема номер три постепенно решается в современный коммерческих DBMS путем расширения набора примитивов, нативно поддерживаемых сервером. В MS SQL 2005 ввели очереди как first-class object.

Остается только проблема номер 1. Ее решение возможно, но оно требует соответствующих усилий при проектировании среднего слоя. Если этим не заниматься специально, то вместо уменьшения нагрузки на RDBMS мы получим дополнительный нагреватель воздуха в серверной.

КЛ>3. linq рулит

На самом деле пока что практики применения линка очень мало, и трудно говорить о том, насколько он сильно рулит. Конкретный Linq2sql — это достаточно специфическая реализация; применен достаточно новый подход к проведению границы между Lightweight и Fullblown, есть масса ограничений (начиная с того, что это фактически linq2mssql). Есть несколько потенциальных вариантов применения технологии линка в рамках 3-tier модели, некоторые тоже уже обсуждались здесь. Про их реальные преимущества можно будет говорить, грубо говоря, тогда, когда выйдет пара-тройка мажорных версий нескольких различных систем, построенных на этих подходах. Издалека и SOAP казался классным.

КЛ>Вопросов 2:


КЛ>1. куда приткнуть линк в трехзвенке _эффективно_? Выставляем вэбсервисы, внутри которых юзаем линк, а на клиенте имеем все те же рукописные BO, которые ws выплевывают?

Не очень понятно, откуда BO на клиенте в трёхзвенке. В трёхзвенке клиент достаточно тонкий, он видит только DTO, ему крайне противопоказано гонять свою логику. Логика отображения, плюс заемная (например, частичная валидация вводимых данных) — вот его удел.
КЛ>Или есть средства для передачи результирующего sql кода на app server и далее app server сам разбирается с сиквелом?
Не очень понятно, что такое "результирующий SQL код"? SQL код формируется внутри апп.сервера и отдается сиквелу на исполнение. Клиент полностью изолирован от SQL кода в каком бы то ни было виде.

У этого подхода есть свои ограничения: в некоторых классах систем происходит экспоненциальный взрыв API апп.сервера из-за чрезмерной узости типичных вебсервисных протоколов.

Сейчас народ постепенно копает идею готовить линк-запросы на клиенте и передавать их апп.серверу. Основные грабли этой идеи — в потенциальном риске. апп.сервер является публичным интерфейсом; если мы не заизолируем пользователей друг от друга, то есть риск получить DoS атаку. Причем изолировать нужно не только "функционально" (когда один клиент не может испортить данные другого), но и по потребляемым ресурсам.

Классический пример — клиент передает на сервер запрос
from T a1 in SomeCollection 
  join a2 in SomeCollection on 1 equals 1 
    join a3 in SomeCollection on 1 equals 1 
    join a4 in SomeCollection on 1 equals 1 
    join a5 in SomeCollection on 1 equals 1 
    join a6 in SomeCollection on 1 equals 1

И если в SomeCollection есть хотя бы тыща элементов, сервер ложится отдыхать.

КЛ>2. чем делать insert/delete/update кроме как не sp?

Как чем? Простой SQL вполне себе подойдет. Вот статья со всеми подробностями.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 22.09.08 21:58
Оценка: 6 (1)
Здравствуйте, IB, Вы писали:

G>>4) Реляционная модель — это не та модель, в которой удобно работать в твоей проге.

IB>Собственно, мой поинт в этой дискуссии ровно в том, что на данный момент, для работы с данными, реляционная модель, таки удобнее любой другой. И лучше работать в ОО с реляционной моделью, чем пытаться из данных строить графы объектов. Другое дело, что идеальным решением может быть что-то еще, но это "что-то еще", определенно сильно смахивает на ту же реляционку.

Я тебе чисто, как настоящий сварщик своему коллеге, скажу в ответ вот что. Вступление.

Лет 10 назад мы с друзьями занимались корпоративными приложениями на базе RDBMS, и были рьяниыми сторонниками нормализации и многоуровневых архитектур.

Потом, жизнь заставила позаниматься 1С. Скажем так, я участвовал в открытии двух стартапов 1С-Франчайзи, в обоих — на ключевых ролях, при этом сам активно выполнял наиболее сложные заказы и переучивал людей с RDBMS на 1С. Плевались страшно. Но бабки есть бабки — 1С реально давал прирост в продуктовности от 2 до 10 (!) раз (измеряли) на большинстве заказов по автоматизации по сравнению с RDBMS с 2+ и 3 звенкой.

Потому, через два года, один мой друг пригласил меня помочь в проектировании системы оперативного учета на базе MS SQL и VB. После ознакомления с требованиями, мы решили отступить от правил нормализации и фактически воспроизвести идеологию 1С в данной системе (справочник-документ-отчет — знаком с ней?).

Суть этой идеологии состоит в значительном отходе от нормализации, и оперировании иерархически структурированными сущностями, близкими к предметной области, с реляционными отношениями между ними. Сущностям соответсвует "справочник". Действиям — "документ". Аналитику ты получаешь на основании ROLAP-звезд, записи в которые вносят действия-"документы", это "отчет". В результате, твоя база данных не только "объектна", она "темпоральна", туда встроена своего рода машина времени. Найдя ошибку в рассчете, ты можешь откатить время назад, исправить ее, и накатить вперед, и ошибка исправится. Правда, удобное свойство? Однако, 1Сv7 был ацки медленным. Нам хотелось те же свойства, только штоб быстро работало. Такое возможно.

Данная методология существенно удобнее в случае бизнес систем как для анализа, так и для разработки. Она на порядок выше уровнем, чем классический подход с ER-BP моделями, и прочим. Я хорошо владею классикой, и знаю что говорю.

Так вот. Эмулируя данный подход поверх реляционной БД, мы получили в меньшие сроки лучше структурированную систему, и не проиграв в производительности. Словили — добавочный геморрой с частичной нормализацией и тем, что бизнес-правила записаны в терминах реляционной модели на TransactSQL, а не в терминах составных документов. То есть, чтобы получить gain в продуктивности, надо поменять концепцию^ и думать не в реляционных терминах — они слишком далеки от бизнеса, налицо semantic gap. А как только начинаешь думать в близких к предметной области терминах, RDBMS только гемор создает.

Так вот, эта модель, "справочник-документ-отчет", отлично ложится на безсхемные базы класса map-reduce. Это просто манна небесная, от какого количества проблем она освобождает. Реляционная модель только создает ненужный гемор, как в анализе, так и в разработке.

Ты говоришь она удобна? Не согласен.
Re[10]: По итогам дискусии напрашивается вопрос
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 01.10.08 10:57
Оценка: 4 (1)
Здравствуйте, Константин Л., Вы писали:

КЛ>ок, интересует архитектура вида pres. layer (asp.net) -> app layer (?) -> sql serv. Причем обмен м/у pres., app, sql через linq (все они физически разнесены). Похоже, что готового решения нет,

Совершенно верно — нет.
КЛ>да и нужно ли оно?
Нужно, хоть и редко. На самом деле, я уверен, что как только появится удачная реализация, ее востребованность резко возрастет. А через пару лет вообще будет считаться, что без этого жить незачем

Вообще, вокруг да около этого копают достаточно много. Помимо упоминавшегося поста Игоря Сухова, я встречал еще давно и такой подход, когда берется некий готовый API (к примеру, RESTаful, или даже SOAP), и к нему делается Linq фронтенд.
Полезные ссылки есть вот здесь. К данному классу относятся:
— Linq to Amazon
— Linq to WebQueries
— Linq to Flickr
— Link to SharePoint
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 16.09.08 20:43
Оценка: 2 (1)
Здравствуйте, Cyberax, Вы писали:

C>И с чем товарищ IB не согласен?

Во-первых, товарищ Cyberax, с тем, что загружать сразу все Items — тоже не лучший вариант для LL, все они могут быть просто не нужны, а нужна лишь часть, отобранная по какому-либо критерию, так что хрен редьки не слаще.
А во-вторых, проблемы начинаются гораздо раньше — не когда LL перестал справляться, а когда не нашли лучшего варианта, чем использовать LL. Собственно, повторю еще раз мысль, уже не однократно озвученную здесь Тохой — LL и ORM-ный кеш служат не для решения проблем приложения, а для решения проблем самой ORM.
ORM, если абстрагироваться от ненужных подробностей — это попытка натянуть на глобус резиновое изделие номер два. Если в конкретном приложении удобно иметь дело с ОО-данными — ставьте полноценную ООБД и не парьте мозг окружающим, половина проблем снимется сразу. Если же хранилище, по каким-то причинам должно быть реляционным, то ORM, которое пытается навернуть объекты на данные, вынуждено прибегать к помощи озвученных LL, кешей и прочих ритуальных приседаний. Если же мы пытаемся использовать ORM по правильному (я вполне верю, что гибернейт с этим отлично справляется =) ), то на зачем оно нам вообще нужно, если с той же задачей те же L2S, BLT и т. д., справляются не хуже?
Безусловно, существует класс приложений, где использование подобного рода инструментов вполне оправдано (но, к слову, там это как правило довольно критичный участок, который все равно пишется отдельно под конкретную задачу), но это скорее исключение. А для большинства рядовых решений использование ORM-ов скорее вредит, так как тащит кучу лишнего кода и провоцирует кривую архитектуру.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 21.09.08 20:09
Оценка: 2 (1)
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Gaperton, Вы писали:


G>>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.

IB>google — не удачный пример... Эти ребята все-таки пишут очень специфичный софт, для очень узкой области.

Google — вполне таки удачный пример. Я говорю конкретно об их BigTable, который не слишком сильно привязан к специфике их софта.

G>> особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.

IB>Меня терзают смутные сомненья. =)
IB>Например, для отчетов оно все равно использует "table-oriented view engine", а различного рода отчеты — это 80%-90% большинства современных приложений.

Во-первых, не только для отчетов. Во-вторых, посмотри внимательно, как именно устроен этот table-oriented view engine. Это имеет не очень много общего с таблицей. Короче, надо чуть больше времени потратить на разбирательство — посмотри как устроен map-reduce . Потом — ты пиши конкретно, что тебе кажется там плохо, я буду отвечать.

G>>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее,

IB>Насколько я понял, ключевое отличие от RDB — нет жесткой схемы данных.
Это важное отличие, но не ключевое. Ключевое отличие в том, что эта схема относительно без проблем масштабируется на ферму из тысяч серверов, и отлично держит "расщепленные сети".

IB>Но как раз благодаря этой самой схеме, современные RDB и демонстрируют всю мощь своих оптимизаторов, поэтому такого рода базы, на современном этапе развития индустрии, потенциально гораздо более тормозные.


На практике — они гораздо более быстрые за счет существенно лучшей масштабируемости. Короче, посмотри как устроены функции map и reduce в справочнике по API. Это примерно 15 минут. Это того стоит, времени потратим меньше. Потом — продолжим разговор.

G>>практически весь геморрой, знакомый по RDB, отсутствует by design.

IB>Какой?

1) Апгрейд схемы БД при изменении версии.
2) Репликация изменений схемы БД.
3) "Нормализация" и понижение производительности из-за обилия операций join. В CouchDB как ключ, так и значения могут быть составным типом произвольной сложности (это произвольные JSON-объекты). Это касается и "table-oreinted view" в том числе.
4) Второй аспект связанный с 3 — это наличие и толщина прослоек и ORM. Реляционная модель — это не та модель, в которой удобно работать в твоей проге. В модели CouchDB семантическая разница в моделях отсутствует, приводить их не надо.
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 19.09.08 16:27
Оценка: 1 (1)
Здравствуйте, Aikin, Вы писали:

A>Cyberax, я его превел не в контексте спора, а сам по себе. Очень правильный закон ограничивающий связность системы. Не стоит о нем забывать.

Чем правильный? Да ещё и хватило наглости назвать это "законом".

A>В частности закон деметры запрещает проектировать классы с вложенными коллекциями в виде: order.Items.Add(newItem) предлагая в замен order.AddItem(newItem).

Вот это и есть неправильно.

A>P.S. Тем более никаким образом он не ограничивает запросы из двух таблиц

Ограничивает. Так как join двух таблиц — тоже нарушение принципа Деметры.

И вообще, можешь показать мне как будет выглядеть "деметрированый" метод, который будет переводить студента в группу к другому студенту?
Sapienti sat!
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 08.09.08 09:53
Оценка: +1
Здравствуйте, z3d, Вы писали:

А>>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


z3d>Linq по своей сути отличается от NHibernate. А вот что можно сравнивать с NHibernate так это ADO Entity Framework, но его пока еще не выпустили.


Вообще-то EF есть в поставке VS2008 SP1.
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 09.09.08 08:30
Оценка: +1
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Ziaw, Вы писали:


Z>>К большому сожалению linq2sql поддерживает только одну СУБД.

IB>А зачем больше?


Z>>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.

IB>Помоему очевидно, что одна библиотека, которая решает конкретную задачу, конкретным способом, будет заведомо качественнее двух библиотек от разных производителей, одна из которых порывается делать все, включая приготовление кофе по расписанию. Разьве нет?

Меня не особо интересует качество ActiveRecord. Что такого навороченного делает ядро NHibernate, чтобы это можно было сравнить с приготовлением кофе? Оно умеет маппить результат сиквел запроса в объекты, делать сиквел запрос из самодельного аналога expression tree и из своего языка запросов. Практически все это умеет делать и linq, только малость беднее функционалом.

Про заведомо качественнее не согласен. Хотя про "очевидно" мы уже спорили с тобой, безрезультатно правда
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 09.09.08 08:39
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Z> Что такого навороченного делает ядро NHibernate, чтобы это можно было сравнить с приготовлением кофе?

Кеш, LL и прочие приседания, которые к мапингу объектов на БД и обратно, имеют весьма посредственное отношение.

Z>Оно умеет маппить результат сиквел запроса в объекты,

Вот если б он только этим и ограничился, я бы тогда с ним смирился.

Z>Практически все это умеет делать и linq, только малость беднее функционалом.

Мой поинт в том, что этот функционал — лишний. Этот функционал направлен как раз на persistent ignorance, а игнорировать это дело нельзя.
Но народ ленив и пытается вообще забыть про СУБД, пользуясь этим функционалом где надо и не надо, последствия чего бывают довольно печальны.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: Lloyd Россия  
Дата: 09.09.08 09:00
Оценка: +1
Здравствуйте, kuj, Вы писали:

IB>>Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.

kuj>Linq2sql не является ORM, как я уже упоминал. Как минимум из-за отсутствия наследования.
Вообще-то в Linq2Sql есть минимальная поддержка наследования. Зачем она только — непонятно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 09.09.08 15:00
Оценка: :)
Здравствуйте, Ziaw, Вы писали:

Z>Кеш второго уровня в NH врядли создаст проблемы если его не использовать.

Зачем он тогда нужен?

Z>С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?

Страшно, что он это умеет. Страшен его язык запросов, страшна идеология того самого присловутого persistance ignorance, ect...

Z>Т.е. проблема инструмента в том, что ты не можешь ограничить его использование в каких-то рамках?

Проблема в том, что он провоцирует забывать о том, что данные лежат во внешнем хранилище.

Z>Не страшно давать народу MSVS? Там же такого кода понаписать можно

Я видел удачные продукты полученные при использовании MSVS, но из них не было ни одного с использованием NH.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 10.09.08 16:18
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, Ziaw, Вы писали:


Z>>С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?


Кэр>Вопрос собственно не в том, что страшного умеет NH. Вопрос в том, что умеет NH, чего не умеет Linq2Sql — и насколько это важно. Я пока стоящих аргументов за NH не видел.


Вопрос был как раз в том, что NH умеет слишком много всего, включая варку кофе Я не агитирую за NH, я знаю недостатки и достоинства этого инструмента. Я не согласен с некоторыми утверждениями холивара против данной библотеки и ORM в целом.

Мне в линке не хватает гибкости и контроля маппингов и поддержки оракла с фаербердом, отсутствие остальных фич NH я готов терпеть за удобство типизации и простоту грануляции запрашиваемых данных.
... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>
Re[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 15.09.08 22:36
Оценка: :)
Здравствуйте, criosray, Вы писали:

Давай по новой.. =)

C> Первая версия EF 1) нарушает принцип persistence ignorance, 2) не имеет implicit lazy loading.

Это все положительные стороны...
Недостатки будут?
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[5]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 16.09.08 09:03
Оценка: :)
Здравствуйте, criosray, Вы писали:

C>С Вами не возможно спорить.

Еще бы, я же прав..

C> Вы отрицаете любое утверждение без какой-либо аргументации.

Я, взволнован. Я аргументов ворох привел, а в ответ получил отмазки из серии "у меня все работает". Не конструктивненько.

C> Думаю пора завязывать с этим непродуктивным спором.

Сломался?
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[5]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 16.09.08 09:13
Оценка: -1
Здравствуйте, criosray, Вы писали:
Просто вся аргументация была уже приведена неоднократно, и даже совсем недавно. Заниматься повторением аргументов каждому новоприбывшему в топик терпения хватает не у многих.
Вкратце могу отослать к другому термину — leaky abstractions. Вот когда абстракции lazy loading и persistence ignorance становятся leaky, тут и вылезают проблемы с масштабированием и производительностью. А эти абстракции протекают легко и часто, что и делает их плохими, в отличие от, скажем, абстракции MSIL.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 16.09.08 13:33
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>>>Абстракции в архитектуре есть всегда. Вообще вся архитектура — это выбор абстракций. Ты имел в виду, что любая абстракция может стать leaky?

C>>Конечно.
C>>Вы это серьезно? Ну и фантазия у Вас...
S>При чем здесь фантазия? Мальчик, сходи почитай хотя бы одноименную статью Спольски.

S>Поясняю для смелых подростков, на пальцах, что значит leaky в применении к lazy loading.


Во-первых, смените тон, уважаемый. Я Вас кажется не оскорблял. Во-вторых, то, что пишите Вы не имеет ничего общего с leaky abstractions. Садитесь — два.
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 16.09.08 21:18
Оценка: +1
Здравствуйте, IB, Вы писали:

C>>И с чем товарищ IB не согласен?

IB>Во-первых, товарищ Cyberax, с тем, что загружать сразу все Items — тоже не лучший вариант для LL, все они могут быть просто не нужны, а нужна лишь часть, отобранная по какому-либо критерию, так что хрен редьки не слаще.
Если нужна часть — то обычно её загружают отдельно (запросом, например). Так что загрузка все коллекции — это прекрасно работающая консервативная стратегия.

IB>А во-вторых, проблемы начинаются гораздо раньше — не когда LL перестал справляться, а когда не нашли лучшего варианта, чем использовать LL. Собственно, повторю еще раз мысль, уже не однократно озвученную здесь Тохой — LL и ORM-ный кеш служат не для решения проблем приложения, а для решения проблем самой ORM.

Опять абсолюты. На практике (лично мне), например, очень часто удобно запросом выделить нужные объекты и работать с ними. LL работает тут как удобный "парашют" для тех случаев, когда нужно взять несколько незагруженных объектов.

И обычно такая стратегия прекрасно работает. Если она перестаёт прекрасно работать — то начинаем оптимизировать начальную загрузку. Т.е. начинаем оптимизацию, когда она mature.

Кстати, возможны и ситуации, когда LL экономит время. Например, если нам достоверно известно, что в ходе выполнения метода понадобится подгрузить всего несколько объектов. Но невозможно заранее сказать каких.

IB>Если же хранилище, по каким-то причинам должно быть реляционным, то ORM, которое пытается навернуть объекты на данные, вынуждено прибегать к помощи озвученных LL, кешей и прочих ритуальных приседаний. Если же мы пытаемся использовать ORM по правильному (я вполне верю, что гибернейт с этим отлично справляется =) ), то на зачем оно нам вообще нужно, если с той же задачей те же L2S, BLT и т. д., справляются не хуже?

В том-то и дело, что справляются хуже. На практике нужна смесь реляционного и объектного подхода.

По историческим причинам так получилось, что лучше всего для этого сейчас подходят RDB+ORM. Возможно, OODB+РБД-расширения подошли бы лучше, но на рынке сейчас нет таких комбинаций за нормальную цену (т.е. $0) и с нормальным качеством.

IB>Безусловно, существует класс приложений, где использование подобного рода инструментов вполне оправдано (но, к слову, там это как правило довольно критичный участок, который все равно пишется отдельно под конкретную задачу), но это скорее исключение.

Все мои приложения под этот класс подходят. Обычно на ORM прекрасно пишется 95% кода, с остальными 5% в виде ручного SQL.
Sapienti sat!
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.09.08 02:59
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Не приведёт. Стандартно для LL — загружать сразу всю коллекцию Items. Так что такой код будет работать вполне прилично.

Ты, наверное, не заметил, что Items — это OrderItems. Каждая, естественно, указывает на отдельную StockItem. И вот тут и начинаются чудеса в решете.
C>У меня вообще ощущение, что если возникают проблемы с LL, то стоит посмотреть не делаем ли мы в коде слишком много лишних действий.
Всё как раз наоборот: чтобы с LL проблем не было, придется делать лишние действия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.09.08 11:20
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>От ошибки: "утащу-ка я всё в ХП".

1. Не вижу, каким образом LWORM и отсутствие LL провоцирует меня "утащить всё в ХП".
2. Не могу понять, почему утаскивание всего в ХП — это ошибка.
3. Продолжаю непонимать, почему ты смешиваешь ошибку неопределенного поведения (которая возникает при выходе за границы) c ошибкой проектирования.

C>Hint: ВСЕ абстракции в какой-то мере leaky. Вопрос в том, перевешивают ли преимущества абстракции её текучесть.

Hint: Вопрос в том, в какой мере абстракция leaky. Абстракции "Remoteness Ignorance" (aka RPC) и "Persistence Ignorance" — leaky как дырявое ведро.


C>Так менять надо.

А так и так менять надо. Только в лайтвейт подходе сразу видно "ок, тут нам потребуются еще и такие данные", а в ORM ты легким манием руки замедляешь страничку в два-три раза, а потом начинаешь бегать с профайлером наперевес, чтоб понять, откуда всё взялось. А оказывается, там у тебя лишний объект поднялся из базы.
C>Особенно замечательно, если получение данных и их отображение достаточно отделены.

S>>А по факту он используется для "неперсистентных графов"?

C>Да. В основном, на графах объектов, полученных в виде XML от автономных узлов у клиентов, или на "толстом" GUI-клиенте.
Интересно было бы посмотреть на эти графы объектов, и каким именно образом у вас достигается единство обработки transient и LL. И нельзя ли это вынести за пределы LL, и обеспечить статический контроль компилятором соответствия алгоритма обрабатываемой модели.

S>>Нет, я не предлагаю опускать такую логику в СУБД. Я всего лишь не понимаю, какое место здесь занимает Lazy Load.

C>Ситуация — человек хочет взять отгул на какой-то день. Мне для принятия решения нужно: контракт этого человека, контракт с агенством, предоставившим этого человека, историю этого человека, статус в профсоюзе, наличие замены этому человеку и т.п.

C>Один только список inner join'ов будет на страницу, если сразу все данные подгружать.

Так, теперь мы уже до inner join договорились. Они-то тут причем?
К тому же, я очень сомневаюсь, что даже если выписать все-все данные, которые тебе понядобятся, получится больше килобайта. Тебе же не полный контракт нужен? Одно поле там, два поля там. Вот и сделай запросы этих данных; и примени формулу.

C>Причём вполне вероятно, что почти все эти данные не потребуются, если первое же правило даст отрицательный результат.


C>Да, и на практике почти все необходимые данные (контракты между кадровым агенством и заказчиком, профсоюзные данные и т.п.) будут висеть в кэше. Следовательно, обращение к ним будет на порядки быстрее запроса к БД.

Ну, нас же волнует не количество cache hit, а количество cache miss. Даже один cache miss — это практически то же самое, как если бы мы честно забрали все данные из базы. А если мы начинаем раздувать кэш, то появляются другие проблемы.

C>Жжжуть. Во-первых, можно сделать lazy loading для отдельных полей (Hibernate это умеет).

Да-да, именно для отдельных. Вот это и превращает схему в Ктулху. ж)
C>Во-вторых, так я бы точно не делал.

C>SQL тогда должен быть достаточно мощным, чтобы соревноваться с Java/C#.

Не надо путать мощность языка с его turing-completeness.

C>>>Если не нравятся длинные пути — просто переходишь на реляционный стиль. В этом и сила ORM.

S>>Ну-ну. И как этот реляционный стиль дружит с транзакциями и кэшем?
C>Нормально дружит. Какие тут проблемы?
Ну вот гибернейт свои запросы где выполняет — в сервере или в кэше? А если у меня в кэше есть измененные объекты, которые всё еще незакоммичены в СУБД, каким образом вычисляются предикаты? А в контексте этой же транзакции?

S>>
S>>from OrderItem i in Connection.OrderItems 
S>>    join StoreItem si on i.StoreItemID equals si.ID
S>>    select si.Name, i.Quantity
S>>

S>>Прямо не знаю, сколько нужно ручной работы .
C>А теперь, пожалуйста, для всех OrderItem'ов, которые находятся в wishlist'е пользователя покажи мне их подробные детали.
Что именно понимается под "подробными деталями"? Ты сомневаешься, что я смогу поджойнить вишлист с ордерайтемами на linq?

C>Потом детали показать ещё для всех item'ов, помеченных количеством звёзд, выше порога, указанного в профиле пользователя.

Перестань — устанет рука.

C>Так не приходится


C>Локальная когерентность кэша решается интеграцией его в ORM. Межузловая когерентность — с помощью кластерных кэшей. Руками его делать — это да, полная дупа.

При чем здесь руками? Речь о том, что чем толще кэш, тем больше затраты на когерентность. Неважно, руками или головой — просто появляется нужда в распределенных транзакциях и оповещениях о сбросе кэша. А это нифига не бесплатно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 18.09.08 09:47
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Объяснить?

Объясни.

S>>Нет. В коде, который я пишу, processor cache miss стоит бесконечно мало по сравнению с временем исполнения запроса.

C>Не так уж мало — замедление при cache miss достигает порядка 20 раз.
Замедление чего? Поясняю: вот у нас на генерацию страницы уходит 20ms. Сколько стоит один processor cache miss? А сколько стоит miss в Hibernate?

C>Ну будет список команд в batch'е на страницу. Разница-то какая?

Разница будет в плане выполнения.

C>Оно только то что нужно подгоняет (ленивые ссылки, однако). Если разбирать на отдельные поля — сильно большого выигрыша не будет, нет у меня там таблиц с килобайтными полями.

Дело не в размере полей, дело в их количестве. Грамотная проекция — это очень хорошо, потому что 80% полей используются только иногда.
S>>Если у тебя на пару контрактов уходит 5 метров, сколько же потребуется для десятков тысяч?
C>Я оцениваю где-то в 10Гб памяти. Сейчас совокупная ёмкость памяти всех узлов — около 40Гб.
Круто. Что тут скажешь. А характерный размер БД какой будет?

S>>Объясни. Мне интересно, как именно происходит чудо.

C>Оптимистическое версирование и никакого мошенничества
То есть каждая транзакция получает свою независимую копию объекта из кэша?

C>Параллельные транзакции изолируются с помощью двухуровневого кэша — один на уровне сессии, другой общий. В общем кэше работает оптимистическое версирование.


C>Перед запросом этот объект будет (по умолчанию) за-flush-ен в БД (без коммита), так что БД вернёт всё корректно.

То есть каждый реляционный запрос приводит к принудительному сбросу накопленных модификаций, и при этом еще и удерживается открытая транзакция???? Копец.

C>Запросы будут расти. А ещё особенно приятно, если оно не всегда нужно будет.

Особенно приятно то, что в LWORM подходе ты как раз выбираешь то, что нужно. Явным образом. Это в FBORM стоит тебе сослаться на VendorInfo, как подтянется всё лишнее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 18.09.08 19:53
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

C>>Объяснить?

S>Объясни.
Объ

C>>Не так уж мало — замедление при cache miss достигает порядка 20 раз.

S>Замедление чего? Поясняю: вот у нас на генерацию страницы уходит 20ms. Сколько стоит один processor cache miss? А сколько стоит miss в Hibernate?
"Один журнал помещаем в серную кислоту, а другой в дистиллированую воду"

Cache miss стоит в Hibernate ровно столько, сколько стоит roundtrip до БД с простейшим запросом (выбор объекта по PK или коллекции по обратной ссылке).

C>>Ну будет список команд в batch'е на страницу. Разница-то какая?

S>Разница будет в плане выполнения.
Детали. Меня больше волнует то, что у нас получатся страницы сложноподдерживаемого кода.

S>Дело не в размере полей, дело в их количестве. Грамотная проекция — это очень хорошо, потому что 80% полей используются только иногда.

Ерунда это. Я нафиг не буду смотреть какие мне поля могут понадобится во всех ветках алгоритма — это сэкономит буквально почти ничего.

C>>Я оцениваю где-то в 10Гб памяти. Сейчас совокупная ёмкость памяти всех узлов — около 40Гб.

S>Круто. Что тут скажешь. А характерный размер БД какой будет?
Пока перешагивает за 5Гб, планируется, что будет прирастать примерно по 3-4Гб в год. Но там большая часть того, что читается вообще всего пару раз за всё время использование приложения. "Горячих" данных сильно больше становиться не будет.

C>>Оптимистическое версирование и никакого мошенничества

S>То есть каждая транзакция получает свою независимую копию объекта из кэша?
Да. Независимые копии нужны ещё для поддержания корректности идентичности объектов.

C>>Перед запросом этот объект будет (по умолчанию) за-flush-ен в БД (без коммита), так что БД вернёт всё корректно.

S>То есть каждый реляционный запрос приводит к принудительному сбросу накопленных модификаций, и при этом еще и удерживается открытая транзакция???? Копец.
Да. Но это не имеет отношения к кэшу второго уровня (разделяемому). Тут даже если ты используешь ТакойЛегковесныйМэпперЧтоОнИмеетОтрицательнуюМассу, то при изменении данных в памяти без их апдейта в БД — не стоит ждать consistency от запросов.

Т.е.:
SomeObject obj=veryLightweightMapper.mapToObject("select .... from some_object...");

obj.setName("New name");

//_Не_ делаем flush
//veryLightweightMapper.saveModified(obj)

SomeObject obj2=veryLightweightMapper.mapToObject("select .... from some_object...");
assert(obj2.getName().equals(obj.getName())); //Ой, а чего это оно???

И Hibernate тут НИЧЕМ не отличается.

С кэшем второго уровня вообще тут всё просто — если объект уже в кэше первого уровня, то второуровневый кэш уже не используется. А для того, чтобы изменить объект — его нужно сначала загрузить, что положит его в кэш первого уровня.

C>>Запросы будут расти. А ещё особенно приятно, если оно не всегда нужно будет.

S>Особенно приятно то, что в LWORM подходе ты как раз выбираешь то, что нужно. Явным образом. Это в FBORM стоит тебе сослаться на VendorInfo, как подтянется всё лишнее.
Ну и? Ты похож на хардкорного С-шника — они тоже используют только то, "что нужно". И нафиг им не нужны эти всякие .NET FW, навязывающие огромную библиотеку классов.

На практике разницы между взятием всего ряда и пары полей почти всегда нет. Тем более, что БД чаще всего хранят все данные ряда в одном месте. Конечно, если используются "колоночные" базы данных и прочая жуть — то вообще о каком-либо ORM стоит забыть, скорее всего.
Sapienti sat!
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.09.08 07:42
Оценка: -1
Здравствуйте, IT, Вы писали:

IT>Это очевидно.


IT>Исторически DAL и прочие ORM появились как адекватный ответ на проблему типизированной работы с источником данных, IT>Вывод таков — объектная модель, предлагаемая ORM по сути своей сегодня являет рудимент и атавизм, тупиковую ветвь


Связи между объектностью модели и типизируемостью нету. Значит исходный посыл ошибошен, значит весь пост ошибочен.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 19.09.08 22:58
Оценка: +1
Здравствуйте, IB, Вы писали:

C>>Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.

IB>Ну, скажем, если эта коллкеция выставлена наружу, как readonly, то не избыточен...
Ну да. Но по моему опыту — тогда просто получаем нагромождение простых методов типа AddItem/RemoveItem/RemoveAllItems, не дающих чего-либо особого.

C>> См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html

IB>Ну, не совсем, это все-таки более общий принцип и имеет отношение не только к данным. Фаулер сосредоточился на частном случае, причем как-то совсем не убедительно.
C>> (правда, Фаулер считает это антипаттерном).
IB>Это исключительно проблемы Фаулера. =)
Ну да, тут совершенно согласен.
Sapienti sat!
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 20.09.08 00:53
Оценка: +1
Здравствуйте, IB, Вы писали:

ANS>> Т.е. конвертация данных в объектную модель — цель существования ORM.

IB>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.
Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.
Sapienti sat!
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 20.09.08 23:27
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>>>Существуют: разные OODB, для мелких БД — Prevayler.

IT>>То что они существуют совершенно не означает, что это альтернатива.
C>RDB сейчас выигрывают только за счёт удобных инструментов и навороченности самих баз. Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

Ты знаешь чем теория отличается от практики?

C>Просто так получилось.


Да хоть как. Главное, что альтернативы RDB сегодня нет.
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 19:20
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Там можно стоить реляционные виды, на которых будет действовать стандартная реляционная алгебра, со всеми вытекающими последствиями.

Иными словами, пока нам производительность не критична, то можем наслаждаться гибкостью?

C>Жёсткая схема.

Я так и понял.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 19:31
Оценка: +1
Здравствуйте, IB, Вы писали:

C>>Там можно стоить реляционные виды, на которых будет действовать стандартная реляционная алгебра, со всеми вытекающими последствиями.

IB>Иными словами, пока нам производительность не критична, то можем наслаждаться гибкостью?
Примерно так. Ну и ещё имеем удобный формат для массивных map-reduce операций, на которых обычные RDB ничем не могут помочь.
Sapienti sat!
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: WolfHound  
Дата: 21.09.08 20:25
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.

Не он один. У нас тоже что-то такое написали.

G>Это уже в ближайшие годы станет популярной и очень серьезной альтернативой RDB,

Это весьма специфичная штука.
У нее свои сценарии использования.
RDB оно может потеснить только в весьма узком сегменте задач.

Я сам думаю над подобной штукой правда с несколько иной моделью и сильно другими целевыми сценариями использования.

G>особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.

Ну я занимаюсь.
Кое где нечто подобное воткнуть можно.
Но на RDB killer'а оно явно не тянет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 22.09.08 09:48
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Зато увеличивает количество мусора, затрудняющего понимание этой системы.

Дело не в количестве мусора. Всё как раз наоборот — если у тебя есть некий граф объектов, то в нем некоторые связи являются избыточными с точки зрения транзитивного замыкания. Принцип Деметеры рекомендует свести граф зависимостей к остовному дереву. Очевидным образом, мы уменьшаем количество мусора (коим являются с точки зрения этого принципа "лишние" связи).

C>Дойдём до максимума — нафиг нам тогда все ассоциации между объектами, если все методы каждого объекта зависят только от своих данных?

Максимум, до которого можно дойти без потери транзитивного замыкания — это остовное дерево.
Его преимущество — это максимальная инкапсуляция, облегчающая рефакторинг и локализующая изменения. При изменении интерфейса одного из классов пострадает только абсолютный минимум классов — те, кто зависит от него напрямую. Классы, расположенные дальше по графу, изолированы от него принципом Деметеры.

A>>Чем же тогда принципиально отличается order.Items.Add(newItem)?

C>Ничем особым.

C>Да. Каждый класс должен работать только со своими данными. А если мы делаем join по цепочке на несколько таблиц — уже интересно получается.

Всегда смешно, когда правила из одной культуры переносят на другую. В join не участвуют никакие классы. Границы декомпозиции проходят совсем в других местах.


C>Тут я согласен — если действие требует нескольких скоординированых операций, то его стоит выносить в хэлперы. А вот однострочные методы — ну их нафиг.

Дело в том, что однострочность — понятие относительное. А вот остовность дерева — абсолютное.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: mogadanez Чехия  
Дата: 22.09.08 21:17
Оценка: :)
ANS>> А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными.
IB>Это заблуждение, к сожалению довольно популярное. Корни его, на самом деле, проистекают из другого, еще более популярного заблуждения — интуитивно-ошибочной интерпретации понятия "ОО программа".

про OO — согласен оно не к месту, но и не с реляционыыми данными.
главное чтобы написаный код могли вместе смотреть заказчик и разработчик,
чтобы когда я буду рядом с ним чтото править по его словам — оно понимал что происходит. чтобы цикл — девеломпент -> фидбек был минимальным.

увы релационные данные не способтвуют этому.
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.09.08 04:00
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Да нифига не рекомендует.

Как это не рекомендует?
C>Мне точно так же может потребоваться работа с объектами, скажем , двумя уровнями ниже текущего.
Может.
C>И то что они все образуют дерево — тут ничего не решает.
Ты, наверное, не понял. Тебе запрещено обращаться "двумя уровнями ниже текущего". Ты будешь обращаться к "одному уровню ниже текущего", а уже он будет обращаться к своему "нижнему уровню". Это понятно?


C>Да и причём оно здесь вообще?

Это математическое представление принципа Деметры.

C>Ну вот чем отличается вот это:

C>
C>select pr.id from prefect pr
C>inner join group grp on pr.parent_group=grp.id
C>inner join student st on st.parent_group=grp.id
C>where st.id=?
C>


C>От вот этого:

C>
C>Prefect pr=someStudent.getParentGroup().getGroupPrefect();
C>

C>?

C>Ну кроме того, что мне потребовалась одна простая строчка там, где тебе придётся писать кучу SQL-кода (или LINQ-кода, не суть важно).

Ну, во-первых код отличается тем, что он написан человеком, укушенным ORM. Неукушенные пишут вот так:
    select pr.id from prefect pr
    inner join student st on pr.parent_group = st.parent_group
    where st.id=?

Укушенные постоянно испытывают тягу к избыточному использованию промежуточных сущностей.

C>И почему "закон" Деметры действует в одном случае, но не действует в другом?

Во-вторых, этот код никакого отношения к принципу Деметры не имеет, поскольку здесь нет разыменования ссылок. Совсем. Достаточно убрать where, и это вообще будет полностью симметричный относительно student и prefect запрос. Никто из них ни к кому не обращается. Вопросы типа "почему этот закон не действует" — то же самое, что и спрашивать "а почему налоговые льготы не применимы к закону всемирного тяготения"?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 23.09.08 08:19
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Я тебе чисто, как настоящий сварщик своему коллеге, скажу в ответ вот что. Вступление.

А я, типа, только каску держал?

G>Лет 10 назад мы с друзьями занимались корпоративными приложениями на базе RDBMS, и были рьяниыми сторонниками нормализации и многоуровневых архитектур.

Нормализация тут непричем. Реляционка хороша тем, что связи там протаптываются с другого конца, чем в OO, в следствии чего любая иерархия строится по месту, а не прибивается гвоздями на этапе проектирования. И такой способ работы с данными удобнее, так как иерархия объектов сильно зависит от конкретного юзкейса и вообще имеет тенденцию эволюционировтаь в процессе эксплуатации приложения и изменениия требований.

G>Так вот, эта модель, "справочник-документ-отчет", отлично ложится на безсхемные базы класса map-reduce.

Посмотрим, если это окажется так, то буду только рад.. С одной стороны "безсхемность" воодушевляет, с другой — одной масштабируемостью в ширь всех проблем с производительностью не вылечишь. Работа с данными характерна тем, что очень плохо размазываются по нескольким серверам и безболезненно масштабировать в ширь можно довольно узкий класс задач. Это очень хорошо видно на tpc-c тестах, где одна большая железка рвет кластеры из 20-40 машин на звездно-полосатый флаг.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.09.08 08:43
Оценка: +1
Здравствуйте, ., Вы писали:

\.>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.
AVK>>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
.>Я имел в виду классический SQL (выросший из реляционной алгебры), в духе какого-нибудь стандарта типа ANSI SQL-99.

Вот как раз в этом стандарте CTE И появились.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 22:04
Оценка: +1
Здравствуйте, IB, Вы писали:

ANS>> Т.е. конвертация данных в объектную модель — цель существования ORM.

IB>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.

Точнее сказать эта работа не реализуема эффективно сама по себе и приводящая к использованию технологии обработки данных которая так же крайне не эффективна.

Собственно современные ОРМ-ы имеют средства поднятия производительности — объектные запросы. Вот только на сегодня не ясно, а зачем тогда все остальные функции ОРМ-ов и зачем тогда сами ОРМ-ы, если запросы можно делать прямо к БД (если она управляется SQL-СУБД)?
Единственный ответ который я вижу на сегодня — это упрощение тех самых запросов за счет устранения (или минимизации) соединения (join) таблиц/коллекций. Однако как раз linq с успехом и очень просто решает эту проблему.
На мой взгляд, linq-у нехватает только наличия удобных DML-операторов (аналогов INSERT, UPDATE, DELETE из SQL) и системы сменных провайдеров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 27.09.08 10:10
Оценка: -1
Здравствуйте, VladD2, Вы писали:

C>>Ну и причём тут OODB, в котором всё точно такое же возможно?

VD>У меня один вопрос. Можно?
Нельзя.

VD>Спасибо!

Пожалуйста.

VD>Так в чем тогда заключается объектность БД если в ней я точно так же описываю список содержащий позиции заказов и потом как-то там связываю конкретные заказы с входящими в них позициями?

Собственно, практически ничем. Кроме того, что элементы кортежей являются типизированным и структурированными.

А типизированный и структурированый элемент — это и есть объект.

VD>Зачем мне для этого объектность? Мне кортежей за глаза хватит! Ну, может для упрощения можно кортежи поименовать и получить стркутуры а-ля С, за неимением которых, скажем в C# мы используем классы. По сути классы в таком подходе — это именованные кортежи.

Да.

VD>Эдак и Оракл является ООБД, так как позволяет хранить именованные "объекты", а не не именованные — кортежи. Не так ли?

Не совсем. Обычно под ООБД понимается система, в которую объектность интегрирована. Оракул такому требованию не отвечает (если забыть на время про его объектные таблицы).
Sapienti sat!
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.08 16:39
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

VD>>У меня один вопрос. Можно?

C>Нельзя.
C>Пожалуйста.
Вы батенька определитесь все же...

VD>>Так в чем тогда заключается объектность БД если в ней я точно так же описываю список содержащий позиции заказов и потом как-то там связываю конкретные заказы с входящими в них позициями?

C>Собственно, практически ничем. Кроме того, что элементы кортежей являются типизированным и структурированными.

Э... Почти все известные мне SQL-СБУД хранят данные типизированно. Все эти varchar(max)/varchar2, int и т.е. — это, что по-твоему, не типы?

Структурированность в РБД — это реляционные отношения и нормализация данных. Так что она тоже есть, но выглядит по другому. Как правильно заметил Ваня реляция позволяет описать отношения данных, а конкретные иерархии строить для конкретных задач.

Может быть речь о наличии вложенных структур? Скажем Оракл позволяет делать вложенные структуры данных в столбцах. Но ты же его не называешь ООБД? Почему?

Или что тогда скрывается за этим термином "структурированными"?

C>А типизированный и структурированый элемент — это и есть объект.


Это, извините, батенька чушь несусветная. В классическом процедурном Паскале были записи. В классическом фунциональном ML-е записи и кортежи. Все эти типы структурированы и статически типизированы, но они не объекты и даже не классы! Это просто комплексные типы данных. Причем кортежи еще и имен не имеют. Кортежи вообще 1 в 1 повторяют описание строк таблиц БД (да и по сути родились из единой теории).

VD>>Зачем мне для этого объектность? Мне кортежей за глаза хватит! Ну, может для упрощения можно кортежи поименовать и получить стркутуры а-ля С, за неимением которых, скажем в C# мы используем классы. По сути классы в таком подходе — это именованные кортежи.

C>Да.

Если ты со мной согласен, то лично я делаю вывод, что ты целиком на нашей стороне, просто путаешь терминологию. Но тогда я не пойму что ты нашел в этом Кибернейте?

VD>>Эдак и Оракл является ООБД, так как позволяет хранить именованные "объекты", а не не именованные — кортежи. Не так ли?

C>Не совсем. Обычно под ООБД понимается система, в которую объектность интегрирована. Оракул такому требованию не отвечает (если забыть на время про его объектные таблицы).

А в чем разница то? Хоть убей не вижу из твоих рассуждений. Ведь если мы пользуемся только POD-типами (структурами и/иди кортежами), то разницы нет никакой. Ну, разве что умозрительная. А вот если мы начинаем по полной программе ООП впихивать (с его полиморфизмом и инкапсуляцией), то как раз и нарываемся на то, что ООП не содержит концепций позволяющих эффективно обрабатывать данные и принуждает к использованию неэффективного навигационного метода работы с данными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.08 16:43
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

VD>>Фундаментальная причина — отсутствие мат.модели объектного хранения данных. ООП был создан для симуляции объектов реального мира в памяти компьютера. Первый ООЯ так и назывался — Симула. Другое ответвление — Смолтолк, что не говорили бы его сторонники, ничего нового в ООП не привнес. Это все то же стимулирование объектов реальной жизни в той же памяти компьютера.

C>Мат.модель для отображения объектов на RDB есть — это реляционная алгебра. Тут ничего нового для OODB не требуется.

Реляционная алгебра — это мат.модель лежащая под РСУБД. Она ни какого отношения к ООП не имеет. Более того. В ней даже терминов "объект" или "класс" нет.

C>Другое дело, что реализации OODB могут отступать от строгой реляционной модели, например, с помощью оптимизации путей доступа к данным. Но то же самое могут делать и RDB.


ООБД не могут пользоваться реляционной алгеброй хотя бы потому, что в итоге получится РСУБД .

И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки. А вот СУБД с движком на основе ООП я почему-то не видел. Плохо смотрел?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 29.09.08 02:50
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>В ней есть термин "кортеж". Классы банально преобразуется в кортежи, а дальше всё просто.

Это чудовищная ересь. Читать определение класса и ООП до просветления.

VD>>И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки.

C>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 29.09.08 07:56
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

C>>А типизированный и структурированый элемент — это и есть объект.

S>Щас прям. Это ты где взял, неужто в хелпе про Хибернейт?
S>Типизированный и структурированный элемент — это record, он value-type в отличие от объекта, который обязан быть reference-типом. Потому, что иначе у него не будет идентичности.
Да, идентичность забыл. Но она тоже обеспечивается с помощью ORM, так что тут тоже не важно.
Sapienti sat!
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 14:29
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Поэтому говорить о том, что "классы банально отображаются на кортежи" можно только от поверхностности, граничащей с некомпетентностью.


Тут, мне кажется, ноги растут от банального самовнушения. Мужик в общем-то стоит на одних позициях с нами. Только вот беда. Когда он занялся вопросом обработки данных в ООП-приложениях, то Линк-а еще не было. Он взял на вооружение то что попалось под руку — Кибирнейт — и переосмыслил его.
Он пропустил мимо ушей все идеологические предпосылки которые даются в первых абзацах первой страницы кибернейтовского сайта (где говорится о персистентности, ООП и другой прозрачностей). Далее он ограничил возможности Кибернэйта возможностями примитивного конвертера с поддержкой нетипизированных запросов и в итоге получил нечто очень похожее н Лник.

Спорить с ним бесполезно, так как мы говорим, о том как Кибернэйм позиционируют его авторы, а он о том виртуальном Кибернейте который был создан его воображением путем ограничения возможностей и перенацеливания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 16:18
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

VD>>Тогда уж "Гибирнейт". Но это уже детали.

C>Ну не нравится мне коверканье английских слов

Это слова такие. Если угодном, могу далее называть его Гибирнейтом. Это и правда ближе к исходному значению.

C>Спасибо, оказывается, что я все эти использовал Hibernate не для того, что нужно.


Оказывается, что так. В прочем, периодически ты оговаривашся, что используешь отложенную загрузку, а значит и траверс по объектам...

VD>>>>Это и LINQ2SQL с успехом делает.

C>>>Это и SQL при желании умеет. Но я имел в виду другое.
VD>>SQL? В нем даже понятия "коллекции" нет. О чем ты?
C>Я же сказал — "при желании".

Я гляжу, ты что угодно "при желании" за уши притянешь. Ну, нельзя же так беседу строить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 01.10.08 18:23
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Спорить с ним бесполезно, так как мы говорим, о том как Кибернэйм позиционируют его авторы, а он о том виртуальном Кибернейте который был создан его воображением путем ограничения возможностей и перенацеливания.


Что интересно, то же самое можно сказать про тебя и линк Ты игноригруешь ORM часть linq2sql и концентрируешься на запросах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sergey T. Украина http://overstore.codeplex.com
Дата: 07.11.08 10:34
Оценка: +1
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Cyberax, Вы писали:


C>> Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

IB>Есть. Фундаментальная причина заключается ровно в том, что OODB жестко привязывает поведение и структуру к данным, а срок жизни данных сильно больше навязанного им поведения, и за их время жизни интерпретация меняется по многу раз. Так что привязывать какое-то конкретное поведение к данным — дурная затея.
....
Вы в чем-то правы, знаете. Но тем не поведение и структура привязаны жестко к данным, может быть, с меньшей гранулярностью и меньшей связанностью, но привязаны.
...
IB>Такая объектность может далеко завести, к примеру, работает у нас сейлз в B2B магазине, для него вполне возможен такой граф объектов Region->Customer->Orders->OrderItems->Product->Vendor... ->Region, упс, граф-то цикличный... Хуже другое, после сейлза пришел вендор-менеджер, а ему от кастомера плясать не интересно, ему граф-то нужен ровно обратный Vendor->Products->OrderItems->Order->Customer. И это мы еще на какого-нибудь логистика не посмотрели, у которого регионы и счета кастомера начинаются прямо от OrderItems и конкретный заказ ему не интересен ему важны все OrderItems до четырех часов сегодняшнего дня, чтобы доставку на завтра спланировать по всем адресам.

Обратите внимание, что вы сами выделили те данные и сущности, интерпретация которых не меняется в зависимости от графа, в котором они находятся. А графы — да черт с ними, графы пусть будут произвольными.

Если вернутся к вопросу преобразования данных — то да, согласен с вами, что данные необходимо бывает и группировать, и вычислять новые данные и т.п.
Но, как правило, эти данные статические. Если в приложении, грубо говоря, нужно только строить по данным отчеты — то там не нужны ОРМ и т.п.

Однако, ситуация меняется, когда данные нужно обрабатывать, то есть когда выделяются такие вот сущности типа Customer->Orders->OrderItems->Product->Vendor... ->Region, и эти сущности нужно редактировать, передавать их как параметры, вызывать какие-нибуть их методы (если они есть). А если к этому нужно добавить и пользовательский интерфейс соответсвующий, и валидацию ввода, и метаданные, и еще чего-нибудь... К данным это добавить тяжелее. Согласитесь. Потому что они "просто данные". Может быть, это и не нужно вам. Можно, также всегда сделать так, что это будет ненужно.
There is no such thing as the perfect design.
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 07.11.08 23:34
Оценка: +1
Здравствуйте, IT, Вы писали:

C>>Но не до такой степени, что при этом становится бесполезным.

IT>Полезность величина субъективная и трудно измеряемая. А вот количество глюков в багтреккере или проведённые в отладчике часы легко можно сосчитать.
Ну сосчитал, и что?

C>>Ну вот как перепоймут — так я и окажусь неправ

IT>Да ты уже неправ, защищая решения, в которые их проблемность заложена в саму архитектуру.
Так это вообще ВСЕ решения.
Sapienti sat!
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Константин Б. Россия  
Дата: 03.12.08 11:04
Оценка: +1
Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, AndrewVK, Вы писали:


A>>>А что такое "табличная часть"?

AVK>>Набор подчиненных персистентных объектов, представляющих строки документа.
A>А атрибуты чем от этого отличаются? По мне это тот же атрибут, только табличного типа.

AVK>>>>Что ты понимаешь под операцией?

A>>>Любое действие над Документом в ходе которого создан регистр.
AVK>>Поскольку действие там ровно одно — проведение, то и идентификаторов никаких не надо.
A>Ну вот смотри. У нас есть Документ (в "ревизии" 0). Над ним произвели 5 действий (получился документ в "ревизии" 5). Эти 5 действий представлены 5-ю Регистрами. Как минимум у регистра есть Id документа и номер "ревизии" в которой Документ был изменен (он же задает последовательность применения Регистров к документу).
A>А правильно ли будет провести анлогию в VCS: Документ == файл под контролем, Регистр == набор изменений для конкретного файла?

Я тоже не разбираюсь в 1С, но я это понял немного по другому. У нас есть Регистр(в "ревизии" 0). Над ним произвели 5 проводок (получился Регистр в "ревизии" 5). Эти 5 проводок представлены 5-ю Документами.
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.12.08 15:32
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

G>Ну, это не принципиально с точки зрения модели, хотя и заставляло идти на разные выкрутасы вроде составных документов. Говорят, в 8-рке это наконец исправили. Вообще, так не должно быть. Я бы предпочел видеть в лице документа и справочника произвольный JSON-объект. И prototype-based объектную модель хранилища. И это, JavaScript вместо языка 1С. И штоб работало в браузере. Это была бы сказка.


Главное что бы операторы по Русски. На каком языке думаю на том и пишу. А по поводу составных документов то и на 7.7 это несложно делать. А еще неплохо вывод типов, интеллисенсе синтаксический контроль.
По поводу разделения Документа и справочника то различе в них только в проведении. А так справочник отвечает за постоянную состовляющую, документ за уникальную. Иерархия и там и там существует. Для документов ввиде подчиненных документов.
и солнце б утром не вставало, когда бы не было меня
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: z3d  
Дата: 08.09.08 09:51
Оценка:
Здравствуйте, Аноним, Вы писали:

А>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


Linq по своей сути отличается от NHibernate. А вот что можно сравнивать с NHibernate так это ADO Entity Framework, но его пока еще не выпустили.

А>2. Далее. Linq в какой-то степени заменяет SQL-запросы. Использовать ли теперь SQL-запросы или все делать через Linq? В каких случаях что использовать?


Если бы я делал с нуля проект, то использовал бы только Linq. Кстати, есть возможность посмотреть, в какие именно SQL-запросы преобразовываются твои выражения на Linq, если волнует вопрос производительности, так что все это контролируемо. Также, никто не мешает получать в Linq результаты вызовова хранимок из БД, если например запрос сложный и надо его на уровне БД реализовать строго определенным образом.

А>3. Если мне максимально быстро нужно сделать сайт с базой. Время запросов имеет не большой смысл -- главное быстро создать сайт. Значит ли это, что мне не нужно использовать ни хранимые процедуры, ни SQL-запросы и можно обойтись только Linq to SQL и Linq?


Вполне. И это будет быстрее, при условии, что не закопаешься в ошибках при использовании непривычного подхода к написанию запросов. Видел целую книжку по Linq, полистал, там некоторые типичные ошибки разбирались, ну то есть тут тоже есть на чем споткнуться
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 08.09.08 09:51
Оценка:
Здравствуйте, Аноним, Вы писали:


А>Заметил, что появился Linq и родственные технологии и активно продвигается. Как теперь канонично работать с базой данных (по стандарту, так сказать)?


А>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


Linq не является ORM. Linq это просто язык запросов. Кстати, есть Linq to NHibernate.

Если сравнивать с NHibernate, то только Entity Framework и пока не в пользу EF.
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: SE Украина  
Дата: 08.09.08 10:15
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Linq не является ORM. Linq это просто язык запросов.

Та его часть, которая DLINQ (или по другому Linq2Sql) вполне справляется с простейшими задачами ORM:
— маппинг полей классов на поля таблиц как с помошью аттрибутов, так и XML файлов описаний.
— очень просто реализуются операции типа CRUD(L).
Глубже просто не копал пока за ненадобностью.

kuj>Если сравнивать с NHibernate, то только Entity Framework и пока не в пользу EF.

Это не подлежит сомнению, но всем ли нужен этот гигант? У LINQ очень низкий уровень вхождения, имхо. Мне хватило пробежать глазами две книжки книжки на английском за один вечер. Это позволяет его действительно быстро встроить в свой проект и при этом не потерять контроль на тем, что же там внутри происходит.
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: SE Украина  
Дата: 08.09.08 10:21
Оценка:
Здравствуйте, Аноним, Вы писали:

А>День добрый.


А>Заметил, что появился Linq и родственные технологии и активно продвигается. Как теперь канонично работать с базой данных (по стандарту, так сказать)?


Большинство примеров по ASP.NET в MSDN все еще пишутся с применением различных DataSource. Например, пришлось немного попотеть, даже просто с прикруткой обычного программного датабиндинга к ListView с DataPager'ами. То одно не работало, то другое от малейшего чиха отваливалось.

С другой стороны после знакомства с Linq старый добрый ObjectDataSource кажется ну совсем тупым и никчемным.
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: Аноним  
Дата: 08.09.08 11:14
Оценка:
Здравствуйте, kuj, Вы писали:

А>>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?


kuj>Linq не является ORM. Linq это просто язык запросов. Кстати, есть Linq to NHibernate.


Имелось в виду Linq2Sql, конечно... А он несомненно является намного более удобным и простым в использовании ORM. Так что думаю гвоздь все-таки забил? Что скажете?
Re[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 08.09.08 11:18
Оценка:
Здравствуйте, SE, Вы писали:

kuj>>Linq не является ORM. Linq это просто язык запросов.

SE>Та его часть, которая DLINQ (или по другому Linq2Sql) вполне справляется с простейшими задачами ORM:
SE>- маппинг полей классов на поля таблиц как с помошью аттрибутов, так и XML файлов описаний.
SE>- очень просто реализуются операции типа CRUD(L).
SE>Глубже просто не копал пока за ненадобностью.
Отсутствуют:
наследование
поддержка value-типов
коллекции только EnitySet (нет даже банального словаря)
SaveOrUpdate механизм(!)
timespan
распределенное кэширование

Очень неудобно работать с транзакциями вне контекста.

kuj>>Если сравнивать с NHibernate, то только Entity Framework и пока не в пользу EF.

SE>Это не подлежит сомнению, но всем ли нужен этот гигант? У LINQ очень низкий уровень вхождения, имхо. Мне хватило пробежать глазами две книжки книжки на английском за один вечер. Это позволяет его действительно быстро встроить в свой проект и при этом не потерять контроль на тем, что же там внутри происходит.

NHibernate очень прост в использовании в простых проектах в действительности.
Есть масса книг, примеров, отличная подробная документация. Есть и обертки типа Castle ActiveRecord (паттерн ActiveRecord из Ruby on Rails)...
Re[5]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 08.09.08 14:28
Оценка:
Здравствуйте, IB, Вы писали:

kuj>>Отсутствуют:

kuj>>наследование
kuj>>поддержка value-типов
kuj>>распределенное кэширование
IB>Это все положительные стороны.
Поясни.

kuj>>SaveOrUpdate механизм(!)

IB>Есть.
Нет.

http://www.nablasoft.com/alkampfer/index.php/2008/03/01/linq-to-sqlworking-with-detatched-object/

kuj>>Очень неудобно работать с транзакциями вне контекста.

IB>И не нужно этого делать.
Работать с транзакциями? Таки нужно.

kuj>>NHibernate очень прост в использовании в простых проектах в действительности.

IB>Не прост, в действительности.

И что же там такого непростого?

С использованием ActiveRecord все вообще элементарно.
Re[7]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 08.09.08 16:09
Оценка:
Здравствуйте, IB, Вы писали:

kuj>>Поясни.

IB>Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.
Linq2sql не является ORM, как я уже упоминал. Как минимум из-за отсутствия наследования. Что до всего остального это очень плохо, что этого там нету. Нет кэширования — нет scalability, нет поддержки нормальных коллекций для мэппинга — нет гибкости и т.д.
NHibernate дает выбор — использовать или нет. Linq2sql такого выбора не дает. Это серьезный минус.

kuj>>Нет.

IB>Ну ладно, нет в том виде, в котором это привыкли видеть в NHibernate, что тоже плюс.
Чем же это плюс? Что я должен задумываться о persist`е объектов, писать дополнительный низкоуровневый код и т.д.? Что в этом хорошего???

kuj>>Работать с транзакциями? Таки нужно.

IB>Работать с транзакциями вне контекста — не нужно.
Есть случаи когда нужно.

kuj>>И что же там такого непростого?

IB>Все в нем не просто и местами довольно криво.
Что именно криво? Что не просто? Давай с конкретными примерами и контр примерами на Linq2Sql.

kuj>>С использованием ActiveRecord все вообще элементарно.

IB>Угу, вот обертку над оберткой использовать — вообще отличная идея.
Мы и так используем обертку надо оберткой надо оберткой и т.д. Вся архитектура ПО уже много лет как строится по принципу слоев.
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: 0K Ниоткуда  
Дата: 08.09.08 21:43
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, IB, Вы писали:


kuj>>>Поясни.

IB>>Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.
kuj>Linq2sql не является ORM, как я уже упоминал.

Т.е. вы имеете в виду полноценной ORM? Т.к. если придерживатся понятий, то очень даже является: wiki/ORM
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 09.09.08 07:54
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.


Сильно сомневаюсь, что г-н IB имеет хоть малейшее представление о таковом.
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 09.09.08 09:06
Оценка:
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Ziaw, Вы писали:


Z>> Что такого навороченного делает ядро NHibernate, чтобы это можно было сравнить с приготовлением кофе?

IB>Кеш, LL и прочие приседания, которые к мапингу объектов на БД и обратно, имеют весьма посредственное отношение.

LL в линке тоже есть, контекст тоже что-то кеширует. Кеш второго уровня в NH врядли создаст проблемы если его не использовать. Тем более локально его не поиспользуешь, только на уровне приложения.

Z>>Оно умеет маппить результат сиквел запроса в объекты,

IB>Вот если б он только этим и ограничился, я бы тогда с ним смирился.

С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?

Z>>Практически все это умеет делать и linq, только малость беднее функционалом.

IB>Мой поинт в том, что этот функционал — лишний. Этот функционал направлен как раз на persistent ignorance, а игнорировать это дело нельзя.
IB>Но народ ленив и пытается вообще забыть про СУБД, пользуясь этим функционалом где надо и не надо, последствия чего бывают довольно печальны.

Т.е. проблема инструмента в том, что ты не можешь ограничить его использование в каких-то рамках? Не страшно давать народу MSVS? Там же такого кода понаписать можно
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re: Взаимодействие с Базой Данных из C# по схеме MS
От: FreddieM  
Дата: 10.09.08 06:59
Оценка:
В тему Linq vs NHibernate и запросов:
Раньше работал с NHibernate проблем не было, с линком сейчас есть проблема — не могу решить. Необходимо объединять таблицы в нетипизированном виде. В NHibernate это просто решается как HQL, так и критериями. А в линк такое, вообще, возможно? Запостил топик, пока никто не ответил
http://www.rsdn.ru/forum/message/3096240.1.aspx
Автор: FreddieM
Дата: 09.09.08
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Кэр  
Дата: 10.09.08 15:22
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?


Вопрос собственно не в том, что страшного умеет NH. Вопрос в том, что умеет NH, чего не умеет Linq2Sql — и насколько это важно. Я пока стоящих аргументов за NH не видел.
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 15.09.08 21:44
Оценка:
Здравствуйте, mashot, Вы писали:

M>1)Последний гвоздь в крышку гроба NHibernate забил Ado.Net Entity Framework.


Возможно и забьет, но не в первой версии. Первая версия EF 1) нарушает принцип persistence ignorance, 2) не имеет implicit lazy loading. Есть еще ряд проблем, но не столь существенных.
Re[4]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 16.09.08 08:41
Оценка:
Здравствуйте, IB, Вы писали:

C>> Первая версия EF 1) нарушает принцип persistence ignorance, 2) не имеет implicit lazy loading.

IB>Это все положительные стороны...
IB>Недостатки будут?
С Вами не возможно спорить. Вы отрицаете любое утверждение без какой-либо аргументации. Думаю пора завязывать с этим непродуктивным спором.
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 16.09.08 09:09
Оценка:
Здравствуйте, IB, Вы писали:


C>>С Вами не возможно спорить.

IB>Еще бы, я же прав..

C>> Вы отрицаете любое утверждение без какой-либо аргументации.

IB>Я, взволнован. Я аргументов ворох привел, а в ответ получил отмазки из серии "у меня все работает". Не конструктивненько.

C>> Думаю пора завязывать с этим непродуктивным спором.

IB>Сломался?

Да-да, Вы правы, я сломался. Только не волнуйтесь так. Это вредно для здоровья.
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 16.09.08 09:59
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Просто вся аргументация была уже приведена неоднократно, и даже совсем недавно. Заниматься повторением аргументов каждому новоприбывшему в топик терпения хватает не у многих.


Не занимайтесь — никто Вас не заставляет.

S>Вкратце могу отослать к другому термину — leaky abstractions.


Спасибо я знаю что такое leaky abstractions. В любой архитектуре могут появиться leaky abstractions. Единственная leaky abstraction в NHibernate это возможность использования SQL напрямую. Честно говоря, даже не знаю зачем ее оставили. На моей практике ни разу не потребовалось прибегать к ней.
Re[7]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 16.09.08 10:43
Оценка:
Здравствуйте, criosray, Вы писали:
C>Спасибо я знаю что такое leaky abstractions.
Непохоже.
C> В любой архитектуре могут появиться leaky abstractions.
Абстракции в архитектуре есть всегда. Вообще вся архитектура — это выбор абстракций. Ты имел в виду, что любая абстракция может стать leaky?
C>Единственная leaky abstraction в NHibernate это возможность использования SQL напрямую. Честно говоря, даже не знаю зачем ее оставили. На моей практике ни разу не потребовалось прибегать к ней.
Непохоже, что ты понимаешь, что такое leaky abstraction. Тебе понятно, почему lazy loading и persistence ignorance — leaky? Если непонятно, то что именно?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 16.09.08 19:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не приведёт. Стандартно для LL — загружать сразу всю коллекцию Items. Так что такой код будет работать вполне прилично.

C>У меня вообще ощущение, что если возникают проблемы с LL, то стоит посмотреть не делаем ли мы в коде слишком много лишних действий.
И с чем товарищ IB не согласен?
Sapienti sat!
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 16.09.08 21:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Если нужна часть — то обычно её загружают отдельно (запросом, например). Так что загрузка все коллекции — это прекрасно работающая консервативная стратегия.

Ага, здесь играем, здесь не играем, а здесь я рыбу заворачивал.. =)

C>На практике (лично мне), например, очень часто удобно запросом выделить нужные объекты и работать с ними.

Вот именно, только причем тут LL?

C>LL работает тут как удобный "парашют" для тех случаев, когда нужно взять несколько незагруженных объектов.

На практике, необходимость такого парашюта означает, что ты просто чего-то не додумал.

C> Т.е. начинаем оптимизацию, когда она mature.

Только мы premature приволокли большую пушку в виде ORM и думаем, как бы использовать все ее красивые возможности, а потом оптимизируем последствия..

C> Например, если нам достоверно известно, что в ходе выполнения метода понадобится подгрузить всего несколько объектов. Но невозможно заранее сказать каких.

Что мешает явно подгрузить, когда станет известно?

C>В том-то и дело, что справляются хуже.

Чем?

C> На практике нужна смесь реляционного и объектного подхода.

А вот здесь отлично себя показывает Linq — не linq2SQL, а просто Linq и порочая функциональщина, и ORM тут совершенно непричем, это уже не их зона ответственности.

C>Все мои приложения под этот класс подходят. Обычно на ORM прекрасно пишется 95% кода, с остальными 5% в виде ручного SQL.

Ага, ты, помнится, хвастался, как пол гибернейта под свою задачу переписал.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.09.08 02:59
Оценка:
Здравствуйте, criosray, Вы писали:
C>Во-первых, смените тон, уважаемый. Я Вас кажется не оскорблял. Во-вторых, то, что пишите Вы не имеет ничего общего с leaky abstractions. Садитесь — два.
Отлично. Статью не читал, значения терминов придумываешь сам. Вместо аргументов будем, значит, фокусироваться на моем тоне. Удачи. Троллей тут игнорят.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 17.09.08 06:32
Оценка:
Здравствуйте, IB, Вы писали:

C>>Если нужна часть — то обычно её загружают отдельно (запросом, например). Так что загрузка все коллекции — это прекрасно работающая консервативная стратегия.

IB>Ага, здесь играем, здесь не играем, а здесь я рыбу заворачивал.. =)
То есть?

C>>На практике (лично мне), например, очень часто удобно запросом выделить нужные объекты и работать с ними.

IB>Вот именно, только причем тут LL?
А потом по связям этих объектов пройтись, с использованием LL.

C>>LL работает тут как удобный "парашют" для тех случаев, когда нужно взять несколько незагруженных объектов.

IB>На практике, необходимость такого парашюта означает, что ты просто чего-то не додумал.
Да. И что из этого?

Я не пишу весь код на ассемблере так, чтобы он идеально работал с кэшами процессора. Так как это мне нафиг не нужно — я больше времени потеряю на разработку, чем выиграю от повышения скорости. С LL ситуация абсолютно аналогичная.

C>> Т.е. начинаем оптимизацию, когда она mature.

IB>Только мы premature приволокли большую пушку в виде ORM и думаем, как бы использовать все ее красивые возможности, а потом оптимизируем последствия..
ORM реально позволяет сократить затраты по времени разработки, так что всё нормально. И использовать ORM совсем несложно.

C>> Например, если нам достоверно известно, что в ходе выполнения метода понадобится подгрузить всего несколько объектов. Но невозможно заранее сказать каких.

IB>Что мешает явно подгрузить, когда станет известно?
Ну а что по-твоему делает LL?

C>>В том-то и дело, что справляются хуже.

IB>Чем?
Сложнее использовать в коде, который ориентирован на объектный стиль использования данных.

C>> На практике нужна смесь реляционного и объектного подхода.

IB>А вот здесь отлично себя показывает Linq — не linq2SQL, а просто Linq и порочая функциональщина, и ORM тут совершенно непричем, это уже не их зона ответственности.
LINQ — он для выбора данных. Ну получишь ты массив анонимных туплов. Что дальше делать с ними?

C>>Все мои приложения под этот класс подходят. Обычно на ORM прекрасно пишется 95% кода, с остальными 5% в виде ручного SQL.

IB>Ага, ты, помнится, хвастался, как пол гибернейта под свою задачу переписал.
Ну не половину, просто некоторые баги в тёмных углах там пофиксил. Оказалось быстрее, чем переписывать всё с нуля.
Sapienti sat!
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 17.09.08 06:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Не приведёт. Стандартно для LL — загружать сразу всю коллекцию Items. Так что такой код будет работать вполне прилично.

S>Ты, наверное, не заметил, что Items — это OrderItems. Каждая, естественно, указывает на отдельную StockItem. И вот тут и начинаются чудеса в решете.
Действительно, не заметил.

Тогда да, стоит загрузить эти объекты сразу.

C>>У меня вообще ощущение, что если возникают проблемы с LL, то стоит посмотреть не делаем ли мы в коде слишком много лишних действий.

S>Всё как раз наоборот: чтобы с LL проблем не было, придется делать лишние действия.
Уже ответил.
Sapienti sat!
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.09.08 08:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>LL тоже даёт тебе функциональное преимущество — возможность писать persistent-unaware код.


"persistent-unaware код" может и хорошо, а вот попытка проигнорировать реляционность нижележащих данных — это значит добровольно отказаться от тех возможностей, которые РСУБД предлагает. А это плохо, и не ясно зачем тогда РСУБД вообще.

И, кстати, не знаю как NHibernate, но сам Hibernate не позволяет писать persistent-unaware код. Для меня в нём остался один бенефит — поддержка разных диалектов SQL и мне зачастую удобнее написать HQL чем эквивалентный SQL.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.09.08 12:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Hint: Вопрос в том, в какой мере абстракция leaky. Абстракции "Remoteness Ignorance" (aka RPC) и "Persistence Ignorance" — leaky как дырявое ведро.


Кстати, на тему RPC есть статья г-на Армстронга (того что с Erlang). Там в коментах еще есть ссылки интересные.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 17.09.08 12:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>От ошибки: "утащу-ка я всё в ХП".

S>1. Не вижу, каким образом LWORM и отсутствие LL провоцирует меня "утащить всё в ХП".
Чтобы сразу загрузить все данные.

S>2. Не могу понять, почему утаскивание всего в ХП — это ошибка.

Не буду сейчас флеймить...

S>3. Продолжаю непонимать, почему ты смешиваешь ошибку неопределенного поведения (которая возникает при выходе за границы) c ошибкой проектирования.

Ну ладно. Ты пишешь код с тщательной проверкой cache-friendlyness? А ведь тут уже приводились horror stories с многодесятикратными замедлениями доступа при промахах по кэшу.

C>>Hint: ВСЕ абстракции в какой-то мере leaky. Вопрос в том, перевешивают ли преимущества абстракции её текучесть.

S>Hint: Вопрос в том, в какой мере абстракция leaky. Абстракции "Remoteness Ignorance" (aka RPC) и "Persistence Ignorance" — leaky как дырявое ведро.
Но тем не менее, иногда полезны. Например, RPC через FibreChannel (с латентностью в микросекунды) — приятнейшая вещь.

S>А так и так менять надо. Только в лайтвейт подходе сразу видно "ок, тут нам потребуются еще и такие данные", а в ORM ты легким манием руки замедляешь страничку в два-три раза, а потом начинаешь бегать с профайлером наперевес, чтоб понять, откуда всё взялось. А оказывается, там у тебя лишний объект поднялся из базы.

Чаще всего замедления просто нет.

S>Интересно было бы посмотреть на эти графы объектов, и каким именно образом у вас достигается единство обработки transient и LL. И нельзя ли это вынести за пределы LL, и обеспечить статический контроль компилятором соответствия алгоритма обрабатываемой модели.

Там у меня сложная система для всего этого Статический контроль — вряд ли, не представляю как это возможно сделать.

C>>Один только список inner join'ов будет на страницу, если сразу все данные подгружать.

S>Так, теперь мы уже до inner join договорились. Они-то тут причем?
Чтоб утащить данные одним запросом.

S>К тому же, я очень сомневаюсь, что даже если выписать все-все данные, которые тебе понядобятся, получится больше килобайта. Тебе же не полный контракт нужен? Одно поле там, два поля там. Вот и сделай запросы этих данных; и примени формулу.

Сейчас померял память — во время выполнения запроса потребление подскакивает на 5Мб. Значит, что-то порядка 500 килобайт данных из БД уходит.

Нужен неполный контракт, но экономить на паре полей там просто смысла нет, не это там bottleneck. Опять же, если пытаться оптимизировать вытягиваемые данные вплоть до поля — получим Ктулху-запрос.

S>Ну, нас же волнует не количество cache hit, а количество cache miss. Даже один cache miss — это практически то же самое, как если бы мы честно забрали все данные из базы. А если мы начинаем раздувать кэш, то появляются другие проблемы.

Объём многих данных сильно ограничен. Скажем, контрактов не будет больше нескольких десятков тысяч — оно всё ложится в кэш и там сидит. Профсоюзных данных тоже не так много, оно тоже всё будет резидентным.

Посмотрел в статистку — cache miss'ов в системе набирается сотня штук за день. Надо бы посмотреть откуда, не должно быть их вообще...

C>>SQL тогда должен быть достаточно мощным, чтобы соревноваться с Java/C#.

S> Не надо путать мощность языка с его turing-completeness.
Ну так не надо путать теоретическую полноту по Тьюрингу и юзабельность.

S>Ну вот гибернейт свои запросы где выполняет — в сервере или в кэше? А если у меня в кэше есть измененные объекты, которые всё еще незакоммичены в СУБД, каким образом вычисляются предикаты? А в контексте этой же транзакции?

Запросы выполняются в БД. Из кэша данные берутся только при простых запросах по PK или lookup'у коллекций. С транзакциями полностью всё совместимо, кэши в Hibernate дают изоляцию READ COMMITED для всей транзакции, при испльзовании пессимистических блокировок — даже REPEATABLE READ.

Могу подробнее объяснить, если интересно.

S>Что именно понимается под "подробными деталями"? Ты сомневаешься, что я смогу поджойнить вишлист с ордерайтемами на linq?

Подробные детали — из объектов DetailedInfo и VendorInfo. Поджойнить ты сможешь без проблем, но представь, что отображение у тебя в generic-коде делается.

S>При чем здесь руками? Речь о том, что чем толще кэш, тем больше затраты на когерентность. Неважно, руками или головой — просто появляется нужда в распределенных транзакциях и оповещениях о сбросе кэша. А это нифига не бесплатно.

Это часто всё равно дешевле, чем работа с БД. У меня как раз сейчас кластерный кэш используется, кстати.
Sapienti sat!
Re[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: WaSh http://kxlm.blogspot.com/
Дата: 17.09.08 18:28
Оценка:
согласен...
... << RSDN@Home 1.2.0 alpha 4 rev. 1108>>
блог http://kxlm.blogspot.com/
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 18.09.08 03:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Чтобы сразу загрузить все данные.

не вижу логики.

S>>3. Продолжаю непонимать, почему ты смешиваешь ошибку неопределенного поведения (которая возникает при выходе за границы) c ошибкой проектирования.

C>Ну ладно. Ты пишешь код с тщательной проверкой cache-friendlyness? А ведь тут уже приводились horror stories с многодесятикратными замедлениями доступа при промахах по кэшу.
Нет. В коде, который я пишу, processor cache miss стоит бесконечно мало по сравнению с временем исполнения запроса.

C>Но тем не менее, иногда полезны. Например, RPC через FibreChannel (с латентностью в микросекунды) — приятнейшая вещь.

Ну, наверное и Persistence Ignorance поверх чего-нибудь экзотического — приятнейшая вещь. Осталось найти, поверх чего именно.

C>Чаще всего замедления просто нет.

По моему опыту, оптимизировать приходится всё. Кроме тех случаев, когда заказчик просто не представляет, как это должно работать, и поэтому тупо терпит все эти часики на экране.

C>Там у меня сложная система для всего этого Статический контроль — вряд ли, не представляю как это возможно сделать.

Лично я как раз хорошо себе представляю. Тебя же не удивляет, что компилятор ухитряется отказываться компилировать итерацию по классам, которые не поддерживают Enumerable pattern?

S>>Так, теперь мы уже до inner join договорились. Они-то тут причем?

C>Чтоб утащить данные одним запросом.
Бред какой-то. Зачем одним запросом-то? Делаешь batch и всех делов .

S>>К тому же, я очень сомневаюсь, что даже если выписать все-все данные, которые тебе понядобятся, получится больше килобайта. Тебе же не полный контракт нужен? Одно поле там, два поля там. Вот и сделай запросы этих данных; и примени формулу.

C>Сейчас померял память — во время выполнения запроса потребление подскакивает на 5Мб. Значит, что-то порядка 500 килобайт данных из БД уходит.
Это ты неправильно меришь. Ты по алгоритму пройдись, посмотри, что ему реально нужно. В то, что ты там мегабайты из базы гоняешь я легко верю — c ORM в это легко наступить.

C>Нужен неполный контракт, но экономить на паре полей там просто смысла нет, не это там bottleneck. Опять же, если пытаться оптимизировать вытягиваемые данные вплоть до поля — получим Ктулху-запрос.

Не получим. Это вы просто SQL готовить не умеете. Вон, уже иннер джойны пошли... С таким подходом вам конечно прямая дорога в ОРМ. Чтоб ктулхов от вас спрятать. Ктулху-игноранс?

C>Объём многих данных сильно ограничен. Скажем, контрактов не будет больше нескольких десятков тысяч — оно всё ложится в кэш и там сидит.

Если у тебя на пару контрактов уходит 5 метров, сколько же потребуется для десятков тысяч?
C>Профсоюзных данных тоже не так много, оно тоже всё будет резидентным.

C>Посмотрел в статистку — cache miss'ов в системе набирается сотня штук за день. Надо бы посмотреть откуда, не должно быть их вообще...


C>Ну так не надо путать теоретическую полноту по Тьюрингу и юзабельность.

Я-то не путаю. Это ты начал рассказывать про то, как неполнота SQL тебе мешает жить.

S>>Ну вот гибернейт свои запросы где выполняет — в сервере или в кэше? А если у меня в кэше есть измененные объекты, которые всё еще незакоммичены в СУБД, каким образом вычисляются предикаты? А в контексте этой же транзакции?

C>Запросы выполняются в БД. Из кэша данные берутся только при простых запросах по PK или lookup'у коллекций. С транзакциями полностью всё совместимо, кэши в Hibernate дают изоляцию READ COMMITED для всей транзакции, при испльзовании пессимистических блокировок — даже REPEATABLE READ.

C>Могу подробнее объяснить, если интересно.

Объясни. Мне интересно, как именно происходит чудо. Каким образом изолируются друг от друга параллельные транзакции, и каким образом достигается целостность реляционных и навигационных операций в рамках одной транзакции. Можешь просто ответить на вопрос: что вернет реляционный запрос, если у меня в кэше есть незакоммиченный объект, модифицированный в этой же транзакции?

C>Подробные детали — из объектов DetailedInfo и VendorInfo. Поджойнить ты сможешь без проблем, но представь, что отображение у тебя в generic-коде делается.

Ну, представляю, и что? В чем проблема-то?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 18.09.08 08:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Чтобы сразу загрузить все данные.

S> не вижу логики.
Объяснить?

C>>Ну ладно. Ты пишешь код с тщательной проверкой cache-friendlyness? А ведь тут уже приводились horror stories с многодесятикратными замедлениями доступа при промахах по кэшу.

S>Нет. В коде, который я пишу, processor cache miss стоит бесконечно мало по сравнению с временем исполнения запроса.
Не так уж мало — замедление при cache miss достигает порядка 20 раз.

C>>Но тем не менее, иногда полезны. Например, RPC через FibreChannel (с латентностью в микросекунды) — приятнейшая вещь.

S>Ну, наверное и Persistence Ignorance поверх чего-нибудь экзотического — приятнейшая вещь. Осталось найти, поверх чего именно.
Hibernate

S> По моему опыту, оптимизировать приходится всё. Кроме тех случаев, когда заказчик просто не представляет, как это должно работать, и поэтому тупо терпит все эти часики на экране.

Обычно эти часики надоедают мне самому ещё при отладке. Так что я их исправляю.

C>>Там у меня сложная система для всего этого Статический контроль — вряд ли, не представляю как это возможно сделать.

S>Лично я как раз хорошо себе представляю. Тебя же не удивляет, что компилятор ухитряется отказываться компилировать итерацию по классам, которые не поддерживают Enumerable pattern?
Это-то примитив, ничего сложного.

C>>Чтоб утащить данные одним запросом.

S>Бред какой-то. Зачем одним запросом-то? Делаешь batch и всех делов .
Ну будет список команд в batch'е на страницу. Разница-то какая?

C>>Сейчас померял память — во время выполнения запроса потребление подскакивает на 5Мб. Значит, что-то порядка 500 килобайт данных из БД уходит.

S>Это ты неправильно меришь. Ты по алгоритму пройдись, посмотри, что ему реально нужно. В то, что ты там мегабайты из базы гоняешь я легко верю — c ORM в это легко наступить.
Оно только то что нужно подгоняет (ленивые ссылки, однако). Если разбирать на отдельные поля — сильно большого выигрыша не будет, нет у меня там таблиц с килобайтными полями.

S>Не получим. Это вы просто SQL готовить не умеете. Вон, уже иннер джойны пошли... С таким подходом вам конечно прямая дорога в ОРМ. Чтоб ктулхов от вас спрятать. Ктулху-игноранс?

Ага. Чтоб с ума не свёл.

C>>Объём многих данных сильно ограничен. Скажем, контрактов не будет больше нескольких десятков тысяч — оно всё ложится в кэш и там сидит.

S>Если у тебя на пару контрактов уходит 5 метров, сколько же потребуется для десятков тысяч?
Я оцениваю где-то в 10Гб памяти. Сейчас совокупная ёмкость памяти всех узлов — около 40Гб.

C>>Ну так не надо путать теоретическую полноту по Тьюрингу и юзабельность.

S>Я-то не путаю. Это ты начал рассказывать про то, как неполнота SQL тебе мешает жить.
Мешает.

C>>Могу подробнее объяснить, если интересно.

S>Объясни. Мне интересно, как именно происходит чудо.
Оптимистическое версирование и никакого мошенничества

S>Каким образом изолируются друг от друга параллельные транзакции, и каким образом достигается целостность реляционных и навигационных операций в рамках одной транзакции.

Параллельные транзакции изолируются с помощью двухуровневого кэша — один на уровне сессии, другой общий. В общем кэше работает оптимистическое версирование.

S>Можешь просто ответить на вопрос: что вернет реляционный запрос, если у меня в кэше есть незакоммиченный объект, модифицированный в этой же транзакции?

Перед запросом этот объект будет (по умолчанию) за-flush-ен в БД (без коммита), так что БД вернёт всё корректно.

C>>Подробные детали — из объектов DetailedInfo и VendorInfo. Поджойнить ты сможешь без проблем, но представь, что отображение у тебя в generic-коде делается.

S>Ну, представляю, и что? В чем проблема-то?
Запросы будут расти. А ещё особенно приятно, если оно не всегда нужно будет.
Sapienti sat!
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 18.09.08 19:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Объ

Случайно обрезалось: для того, чтобы определить какие данные нужно загрузить — часто нужна сама по себе неслабая логика. Если её делать в SQL-батчах, то её как-то придётся на SQL и записывать.

C>Пока перешагивает за 5Гб, планируется, что будет прирастать примерно по 3-4Гб в год. Но там большая часть того, что читается вообще всего пару раз за всё время использование приложения. "Горячих" данных сильно больше становиться не будет.

Блин, хотел написать 50Гб и 30-40Гб в год.
Sapienti sat!
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 19.09.08 08:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

Law Of Demeter?
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 19.09.08 08:21
Оценка:
Здравствуйте, Aikin, Вы писали:

C>>Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

A>Law Of Demeter?
Тогда он периодически нарушается в реляционных БД в запросах, затрагивающих более двух таблиц.
Sapienti sat!
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 19.09.08 08:24
Оценка:
Здравствуйте, Aikin, Вы писали:

C>>Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

A>Law Of Demeter?
Кстати, он ещё и противоречит принципу, что методы класс должны заниматься только тем, что требует доступа к его приватным данным.
Sapienti sat!
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.09.08 08:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ерунда это. Я нафиг не буду смотреть какие мне поля могут понадобится во всех ветках алгоритма — это сэкономит буквально почти ничего.


Полей — может и ерунда. А отсутсвие необходимости декларировать используемые сущности приводит к тому, что невозможно понять какому куску кода какие данные нужны и когда они будут загружены. Значит нельзя вычленить кусок кода которому для работы доступ к БД не нужен. Это приводит к принципиальной немногопоточности.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 19.09.08 09:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

A>>Law Of Demeter?
C>Тогда он периодически нарушается в реляционных БД в запросах, затрагивающих более двух таблиц.
Cyberax, я его превел не в контексте спора, а сам по себе. Очень правильный закон ограничивающий связность системы. Не стоит о нем забывать.

В частности закон деметры запрещает проектировать классы с вложенными коллекциями в виде: order.Items.Add(newItem) предлагая в замен order.AddItem(newItem).

СУВ, Aikin

P.S. Тем более никаким образом он не ограничивает запросы из двух таблиц
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 19.09.08 09:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

A>>Law Of Demeter?
C>Кстати, он ещё и противоречит принципу, что методы класс должны заниматься только тем, что требует доступа к его приватным данным.
1) Каким это образом? Тем, что он не запрещает?
2) Что это за принцип-то такой? Не мог бы ты полнее его озвучить?


СУВ, Aikin
Re[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 19.09.08 13:23
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Связи между объектностью модели и типизируемостью нету.


А что по твоему есть типизируемость в C#?

ANS>Значит исходный посыл ошибошен, значит весь пост ошибочен.


Посыл не просто не ошибочый, а единственно возможный. Я тебе даже мог бы в подробностях рассказать как всё началось, но сначала тебе домашнее задание — найти связь между типизацией и объектной моделью
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.09.08 14:27
Оценка:
Здравствуйте, IT, Вы писали:

ANS>>Связи между объектностью модели и типизируемостью нету.


IT> А что по твоему есть типизируемость в C#?


По твоему объектаная модель может быть только в C#?


IT>тебе домашнее задание — найти связь между типизацией и объектной моделью


нельзя найти то, чего нет

ORM появились появились еще в Smalltalk, где проверка типизированности данных не требование. А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными. Т.е. конвертация данных в объектную модель — цель существования ORM.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 19.09.08 16:25
Оценка:
Здравствуйте, Aikin, Вы писали:

C>>Кстати, он ещё и противоречит принципу, что методы класс должны заниматься только тем, что требует доступа к его приватным данным.

A>1) Каким это образом? Тем, что он не запрещает?
Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.

A>2) Что это за принцип-то такой? Не мог бы ты полнее его озвучить?

Да очень простой принцип, неоднократно обсуждали в форуме по архитектуре. См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html (правда, Фаулер считает это антипаттерном).
Sapienti sat!
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 19.09.08 16:28
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Полей — может и ерунда. А отсутсвие необходимости декларировать используемые сущности приводит к тому, что невозможно понять какому куску кода какие данные нужны и когда они будут загружены. Значит нельзя вычленить кусок кода которому для работы доступ к БД не нужен. Это приводит к принципиальной немногопоточности.

То что ты рассказывал как у вас там всё работает — это чистый антипаттерн использования Hibernate. У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.
Sapienti sat!
Re[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gadsky Россия  
Дата: 19.09.08 19:21
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>для кого войны, а для кого очень хороший источник информации о в общем-то проблемном вопросе. мне, например, интересно читать такие разные точки зрения, + по ходу дела всплывают не совсем относящиеся к теме, но не менее важные вопросы.


А>поэтому продолжайте господа, вас приятно слушать!


+1.

Все равно мы все понимаем, что каждой технологии свое место .

Кстати, приятно отметить, что это-таки не священные войны, а вполне аргументированная дискуссия (нуу, на 70%).

Так что, продолжайте, господа! Мы очень внимательно вас слушаем.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 19.09.08 22:47
Оценка:
Здравствуйте, Cyberax, Вы писали:

ANS>> А отсутсвие необходимости декларировать используемые сущности приводит к тому, что невозможно понять какому куску кода какие данные нужны и когда они будут загружены. Значит нельзя вычленить кусок кода которому для работы доступ к БД не нужен.

C>У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.
Каким образом создание отдельной сессии на поток позволит разобраться, кода какие данные нужны и когда они будут загружены?
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 19.09.08 22:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.

Ну, скажем, если эта коллкеция выставлена наружу, как readonly, то не избыточен...

C> См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html

Ну, не совсем, это все-таки более общий принцип и имеет отношение не только к данным. Фаулер сосредоточился на частном случае, причем как-то совсем не убедительно.

C> (правда, Фаулер считает это антипаттерном).

Это исключительно проблемы Фаулера. =)
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[29]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 19.09.08 23:01
Оценка:
Здравствуйте, IB, Вы писали:

C>>У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.

IB>Каким образом создание отдельной сессии на поток позволит разобраться, кода какие данные нужны и когда они будут загружены?
У товарища ANS проблема в том, что граф объектов одновременно обходится из нескольких потоков. При этом попытки сделать lazy-loading сразу из двух потоков вызывают недоумение со стороны Hibernate.

Если бы каждый поток работал со своими личными объектами — такой проблемы не было бы.
Sapienti sat!
Re[5]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 19.09.08 23:05
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS> ORM появились появились еще в Smalltalk, где проверка типизированности данных не требование.

А динамическая типизация, за типизацию уже не катит?

ANS> А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными.

Это заблуждение, к сожалению довольно популярное. Корни его, на самом деле, проистекают из другого, еще более популярного заблуждения — интуитивно-ошибочной интерпретации понятия "ОО программа".

ANS> Т.е. конвертация данных в объектную модель — цель существования ORM.

Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[30]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 20.09.08 05:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, IB, Вы писали:


C>У товарища ANS проблема в том, что граф объектов одновременно обходится из нескольких потоков.

Это-то понятно. Тем не менее, вопрос был задан совершенно четко — что делать с тем, что непонятно, когда какие данные нужны и когда они будут загружены?
Собственно, это порождает целый ворох проблем, как с производительностью, так и с поддержкой кода...

C>Если бы каждый поток работал со своими личными объектами — такой проблемы не было бы.

Стоп — стоп. Это я что, вынужден в прикладном коде разруливать с какой сессией какой поток работает?!! Афигеть удобство.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 20.09.08 15:17
Оценка:
Здравствуйте, IB, Вы писали:

C>>У товарища ANS проблема в том, что граф объектов одновременно обходится из нескольких потоков.

IB>Это-то понятно. Тем не менее, вопрос был задан совершенно четко — что делать с тем, что непонятно, когда какие данные нужны и когда они будут загружены?
Использовать ленивую загрузку.

C>>Если бы каждый поток работал со своими личными объектами — такой проблемы не было бы.

IB>Стоп — стоп. Это я что, вынужден в прикладном коде разруливать с какой сессией какой поток работает?!! Афигеть удобство.
А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай. Так как множество wire-протоколов баз данных — не threadsafe и не параллельные. Ну и JDBC-драйверы, соответственно, тоже не-threadsafe.
Sapienti sat!
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 20.09.08 15:18
Оценка:
Здравствуйте, IT, Вы писали:

C>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

IT>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.
Существуют: разные OODB, для мелких БД — Prevayler.
Sapienti sat!
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 20.09.08 22:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

IT>>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.
C>Существуют: разные OODB, для мелких БД — Prevayler.

То что они существуют совершенно не означает, что это альтернатива.
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 20.09.08 23:39
Оценка:
Здравствуйте, IT, Вы писали:

C>>RDB сейчас выигрывают только за счёт удобных инструментов и навороченности самих баз. Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

IT>Ты знаешь чем теория отличается от практики?
Тем что в теории не отличается

C>>Просто так получилось.

IT>Да хоть как. Главное, что альтернативы RDB сегодня нет.
Я лично сделал пару мелких проектов на db4o. Всё без особых проблем работает, инструменты удовлетворительны. Так что альтернативы есть, если посмотреть.

Для больших проектов пока просто боюсь использовать.
Sapienti sat!
Re[32]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 16:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

IB>>Это-то понятно. Тем не менее, вопрос был задан совершенно четко — что делать с тем, что непонятно, когда какие данные нужны и когда они будут загружены?

C>Использовать ленивую загрузку.
Не, ты не понял — в следствии ленивой загрузки мне по прежнему не понятно, что, когда и почему будет загружено.

C>А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай.

Чтобы не пришлось, надо не насвистывать, а явно открывать и закрывать соединение с базой при каждом обращении — дешево и сердито, и никакой ручной синхронизации потоков с приседаниями вокруг сессий.

C> Так как множество wire-протоколов баз данных — не threadsafe и не параллельные. Ну и JDBC-драйверы, соответственно, тоже не-threadsafe.

Причем тут протоколы? Меня это не парит совешенно, синхронизацией пусть база занимается, у нее это получается лучше всех.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[33]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 17:33
Оценка:
Здравствуйте, IB, Вы писали:

C>>Использовать ленивую загрузку.

IB> Не, ты не понял — в следствии ленивой загрузки мне по прежнему не понятно, что, когда и почему будет загружено.
Ну отключаем ленивую загрузку и смотрим откуда исключения прилетят.

C>>А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай.

IB>Чтобы не пришлось, надо не насвистывать, а явно открывать и закрывать соединение с базой при каждом обращении — дешево и сердито, и никакой ручной синхронизации потоков с приседаниями вокруг сессий.
Ну да, и при этом теряем границы транзакций (потенциальные спецэффекты, привет!).

В Hibernate так при желании тоже делается — пишется LazyLoadingHandler, который каждый раз открывает новую сессию на один запрос.

C>> Так как множество wire-протоколов баз данных — не threadsafe и не параллельные. Ну и JDBC-драйверы, соответственно, тоже не-threadsafe.

IB>Причем тут протоколы? Меня это не парит совешенно, синхронизацией пусть база занимается, у нее это получается лучше всех.
У Андрея проблема в том, что с одним соединением идёт работа из нескольких потоков. Все известные БД на таком use-case'е глючат.
Sapienti sat!
Re[34]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 18:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну отключаем ленивую загрузку и смотрим откуда исключения прилетят.

Нельзя, все встанет — это же ORM. )

C>Ну да, и при этом теряем границы транзакций (потенциальные спецэффекты, привет!).

С какого перепугу. Все траназакции в рамках этого самого коннекта, наоборот — это гарантия отсутствия спецэффектов. Нет никакой нужды границы транзакций размазывать.

C>В Hibernate так при желании тоже делается — пишется LazyLoadingHandler, который каждый раз открывает новую сессию на один запрос.

То есть написание LLHandler-а — это средство облегчения работы при использовании ORM? Я лучше это время потрачу на написание прикладного кода.. ))

C>У Андрея проблема в том, что с одним соединением идёт работа из нескольких потоков. Все известные БД на таком use-case'е глючат.

Так с соединением или с гибернейтовской сессией?
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 18:19
Оценка:
Здравствуйте, IB, Вы писали:

C>> Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

IB>Есть. Фундаментальная причина заключается ровно в том, что OODB жестко привязывает поведение и структуру к данным, а срок жизни данных сильно больше навязанного им поведения, и за их время жизни интерпретация меняется по многу раз.
Схема БД тоже жёстко привязывает структуру данных и поведение. Изменишь структуру данных — и поведение сломается. Не вижу НИКАКОЙ разницы.

IB>Ну возьми реальное приложение, которое работает с данными, на кой байт тебе там полноценный граф объектов? У такой модели хорошо получается только добираться до одного элемента по индексу, но на самом-то деле нужно фильтровать, объеденять, сортировать, агрегировать, причем самым произвольным образом, а на всех этих операциях ОО сосет как промышленный пылесос, по сравнению с моделью старика Кодда. В плоть до того, что для решения таких задач в насквозь объектный C# вкрячили функциональный LINQ, так похожий на SQL, что с двух шагов не отличить.

Ну и причём тут OODB, в котором всё точно такое же возможно?

IB>Такая объектность может далеко завести, к примеру, работает у нас сейлз в B2B магазине, для него вполне возможен такой граф объектов Region->Customer->Orders->OrderItems->Product->Vendor... ->Region, упс, граф-то цикличный... Хуже другое, после сейлза пришел вендор-менеджер, а ему от кастомера плясать не интересно, ему граф-то нужен ровно обратный

Ну и кто мешает? У меня в модели полно таких циклов. И всё работает.

IB>И весь этот зоопарк костылей нужен вместо того, чтобы просто сказать базе — "дай мне пожалуйста всех вендоров, продукты которых мы продали в таких-то регионах, на сумму больше Z у. е." и получить от нее ровно ту информацию, которая нужна (к слову, в виде объекта), а не полный граф от вендора до кастомера.

Слушай, ты вообще с OODB работал или только в теории говоришь? Так как всё это там делается ну точно так же, как и в RDB.
Sapienti sat!
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 21.09.08 18:23
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.


G>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google. Это уже в ближайшие годы станет популярной и очень серьезной альтернативой RDB, особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.


Я занимаюсь всем подряд. Решение о том, будет ли моё приложение web-based принимается в основном исходя из соображений какая аудитория будет у этого приложения. Если у него будут outside юзеры, то скорее всего это будет web-based. Иначе WPF. К сожалению. у веба есть порог функциональной сложности, связанный с передачей состояния между клиентом и сервером, когда сложность такого приложения начинает зашкаливать все разумные пределы.

G>Сейчас — они поднимаются по хайпу, скоро будут на пике.


Если появится достойная альтернатива, то я буду только рад Мне как пользователю технологий любая конкуренция только на руку. Но пока я не вижу достойных альтернатив.
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[35]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 18:31
Оценка:
Здравствуйте, IB, Вы писали:

C>>Ну отключаем ленивую загрузку и смотрим откуда исключения прилетят.

IB>Нельзя, все встанет — это же ORM. )
Почему? У нас просто получится решение, изоморфное решению без ORM.

Хотя если ты считаешь, что без ORM писать — это "всё встанет", то тут согласен.

C>>Ну да, и при этом теряем границы транзакций (потенциальные спецэффекты, привет!).

IB>С какого перепугу. Все траназакции в рамках этого самого коннекта, наоборот — это гарантия отсутствия спецэффектов. Нет никакой нужды границы транзакций размазывать.
Транзакции должны соответствовать одной единице работы.

C>>В Hibernate так при желании тоже делается — пишется LazyLoadingHandler, который каждый раз открывает новую сессию на один запрос.

IB>То есть написание LLHandler-а — это средство облегчения работы при использовании ORM? Я лучше это время потрачу на написание прикладного кода.. ))
Это просто как вариант решения. Писать, кстати, его не надо — на сайте Hibernate есть готовый в разделе примеров.

C>>У Андрея проблема в том, что с одним соединением идёт работа из нескольких потоков. Все известные БД на таком use-case'е глючат.

IB>Так с соединением или с гибернейтовской сессией?
С обоими.
Sapienti sat!
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 18:34
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.

google — не удачный пример... Эти ребята все-таки пишут очень специфичный софт, для очень узкой области.

G> особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.

Меня терзают смутные сомненья. =)
Например, для отчетов оно все равно использует "table-oriented view engine", а различного рода отчеты — это 80%-90% большинства современных приложений.

G>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее,

Насколько я понял, ключевое отличие от RDB — нет жесткой схемы данных. Но как раз благодаря этой самой схеме, современные RDB и демонстрируют всю мощь своих оптимизаторов, поэтому такого рода базы, на современном этапе развития индустрии, потенциально гораздо более тормозные.

G>практически весь геморрой, знакомый по RDB, отсутствует by design.

Какой?
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 18:45
Оценка:
Здравствуйте, IB, Вы писали:

G>>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее,

IB>Насколько я понял, ключевое отличие от RDB — нет жесткой схемы данных. Но как раз благодаря этой самой схеме, современные RDB и демонстрируют всю мощь своих оптимизаторов, поэтому такого рода базы, на современном этапе развития индустрии, потенциально гораздо более тормозные.
Там можно стоить реляционные виды, на которых будет действовать стандартная реляционная алгебра, со всеми вытекающими последствиями.

G>>практически весь геморрой, знакомый по RDB, отсутствует by design.

IB>Какой?
Жёсткая схема.
Sapienti sat!
Re[36]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 18:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Почему? У нас просто получится решение, изоморфное решению без ORM.

Мы уже выяснили, что без LL ORM не живет, а вот если делать без ORM то и без LL вполне можно обойтись.

C>Хотя если ты считаешь, что без ORM писать — это "всё встанет", то тут согласен.

Я считаю ровно наоборот.

C>Транзакции должны соответствовать одной единице работы.

Единице работы чего? И какие транзакции? Еденице бизнес-работы, должна соответствовать бизнес-транзакция, но бизнес-транзакция совсем не должна соответствовать транзакции в БД. Я бы даже сказал наоборот, должна не соответствовать.

C>Это просто как вариант решения.

Другие есть?

C>С обоими.

То есть, при работе с гибернейтовской сессией, я должен следить за доступом к ней из различных потоков?
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[37]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 19:08
Оценка:
Здравствуйте, IB, Вы писали:

C>>Почему? У нас просто получится решение, изоморфное решению без ORM.

IB>Мы уже выяснили, что без LL ORM не живет, а вот если делать без ORM то и без LL вполне можно обойтись.
ORM вполне без LL прекрасно живёт, просто вырождается в решение аналогичное тому, что получится без ORM. Если это необходимо в каких-то случаях, то никто не запрещает использовать.

C>>Транзакции должны соответствовать одной единице работы.

IB>Единице работы чего? И какие транзакции? Еденице бизнес-работы, должна соответствовать бизнес-транзакция, но бизнес-транзакция совсем не должна соответствовать транзакции в БД. Я бы даже сказал наоборот, должна не соответствовать.
Насколько я понимаю, там как раз в одной единице бизнес-работы и была многопоточная (для ускорения) работа.

C>>Это просто как вариант решения.

IB>Другие есть?
Есть.

C>>С обоими.

IB>То есть, при работе с гибернейтовской сессией, я должен следить за доступом к ней из различных потоков?
Ровно так же, как ты должен следить за тем, что одно соединение с БД не используется из нескольких потоков.
Sapienti sat!
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 19:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Схема БД тоже жёстко привязывает структуру данных и поведение.

Не привязывает. Между структурой данных и поведением есть запросы.

C> Не вижу НИКАКОЙ разницы.

Сочувствую...

C>Ну и причём тут OODB, в котором всё точно такое же возможно?

При том, что из-за гораздо более суровых связей, сделать это весьма проблематично и нерентабельно, потому и не сделали.

C>Ну и кто мешает? У меня в модели полно таких циклов. И всё работает.

Конечно работает, у тебя же полный зоопарк — LL, кеши, DTO — только вот зачем это все?

C>Слушай, ты вообще с OODB работал или только в теории говоришь?

Я в практике говорю.

C> Так как всё это там делается ну точно так же, как и в RDB.

Ага. Так нафига мне объекты в OODB или граф объектов от ORM, если в приложении, для реализации конкретного юзкейса, мне нужны совсем другие объекты?
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[38]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 19:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>ORM вполне без LL прекрасно живёт, просто вырождается в решение аналогичное тому, что получится без ORM.

Это понятно, собственно об этом и речь. Чтобы использовать ORM с полноценным графом объектов мы вынуждены подключать LL.

C>Если это необходимо в каких-то случаях, то никто не запрещает использовать.

Но так как это самый частый сценарий, то возникает вопрос — нафига мне нужна ORM?

C>Насколько я понимаю, там как раз в одной единице бизнес-работы и была многопоточная (для ускорения) работа.

Ну и причем тут тогда транзакции? Ты от темы то не увиливай.

C>Есть.

Какие?

C>Ровно так же, как ты должен следить за тем, что одно соединение с БД не используется из нескольких потоков.

Причем тут соединение? Не уворачивайся, мы уже по кругу идем, как поступают с соединением я тебе уже рассказал. Поступать так с сессией смысла не имеет, так как теряется сам смысл сессии.
Отсюда можно сделать вывод, что при работе с сессиями гибернейта, надо в ручную разруливать многопоточность, что является конкретным косяком.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 19:19
Оценка:
Здравствуйте, IB, Вы писали:

C>>Схема БД тоже жёстко привязывает структуру данных и поведение.

IB>Не привязывает. Между структурой данных и поведением есть запросы.
Которые есть часть поведения, и которые ломаются от изменения структуры данных.

C>>Ну и причём тут OODB, в котором всё точно такое же возможно?

IB>При том, что из-за гораздо более суровых связей, сделать это весьма проблематично и нерентабельно, потому и не сделали.
Нет, просто у RDB получилась фора примерно в 10 лет, которой они воспользовались. Cache' вон вполне себе нормально живёт, и рвёт RDB на многих задачах.

C>>Ну и кто мешает? У меня в модели полно таких циклов. И всё работает.

IB>Конечно работает, у тебя же полный зоопарк — LL, кеши, DTO — только вот зачем это все?
А без ORM оно не нужно?

C>>Слушай, ты вообще с OODB работал или только в теории говоришь?

IB>Я в практике говорю.
Что-то не очень похоже.

C>> Так как всё это там делается ну точно так же, как и в RDB.

IB>Ага. Так нафига мне объекты в OODB или граф объектов от ORM, если в приложении, для реализации конкретного юзкейса, мне нужны совсем другие объекты?
А зачем "совсем другие"?
Sapienti sat!
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 20:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.

WH>Не он один. У нас тоже что-то такое написали.
Их сейчас все кому не лень пишут Мы вот используем Apache Hadoop на Amazon EC2 для построения некоторых отчётов. Очень круто — можно по запросу получить сотню готовых машинок на пару часов.

G>>особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.

WH>Ну я занимаюсь.
WH>Кое где нечто подобное воткнуть можно.
WH>Но на RDB killer'а оно явно не тянет.
Оно особо рулит там, где нужна работа с документами, и особенно с версироваными документами.
Sapienti sat!
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 21:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Которые есть часть поведения, и которые ломаются от изменения структуры данных.

Эта часть поведения очень хорошо отделяется от собственно поведения и структуры хранения, а не является неотъемлемой частью объекта, как в OODB и классических ORM.

C>Нет, просто у RDB получилась фора примерно в 10 лет, которой они воспользовались.

После этой форы прошло уже лет 20, пора бы фору и наверстать уже. К тому же, иерархические БД и тем более сетевые, в этом разрезе, мало чем отличаются от OODB, так что на самом деле и форы никакой не было, наоборот, у такого подхода было преимущество, так как появился он раньше.

C> Cache' вон вполне себе нормально живёт, и рвёт RDB на многих задачах.

Не на многих, а на очень конкретных и весьма консервативных — во-первых, эти задачи весьма специфичны, а во-вторых, в силу консервативности, там просто нет смысла переходить на RDB, раз и так работает. Собственно, Cache сейчас выступает ровно там, где всегда были сетевые БД и на реляционные так и не перешли.

C>А без ORM оно не нужно?

Нет конечно. LL и DTO — не нужны, кеш нужен совсем в другом виде.

C>А зачем "совсем другие"?

Затем, что прикладная логика существенно многообразнее того, что нужно хранить, и меняется эта логика гораздо чаще сохраненных данных. Собственно с чего и начали — это фундаментальная разница, между собственно данными и их интерпретацией в конкретном юзкейсе конкретного приложения. "Data != Object" (c)
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 21.09.08 22:06
Оценка:
Здравствуйте, IB, Вы писали:

C>>Которые есть часть поведения, и которые ломаются от изменения структуры данных.

IB>Эта часть поведения очень хорошо отделяется от собственно поведения и структуры хранения, а не является неотъемлемой частью объекта, как в OODB и классических ORM.
Она отделяется ровно в той мере, в которой объекты отделены от схемы БД в ORM.

IB>После этой форы прошло уже лет 20, пора бы фору и наверстать уже. К тому же, иерархические БД и тем более сетевые, в этом разрезе, мало чем отличаются от OODB, так что на самом деле и форы никакой не было, наоборот, у такого подхода было преимущество, так как появился он раньше.

Иерархические БД — отличаются, слишком они примитивные. Сетевые БД — уже ближе, да.

C>> Cache' вон вполне себе нормально живёт, и рвёт RDB на многих задачах.

IB>Не на многих, а на очень конкретных и весьма консервативных — во-первых, эти задачи весьма специфичны, а во-вторых, в силу консервативности, там просто нет смысла переходить на RDB, раз и так работает. Собственно, Cache сейчас выступает ровно там, где всегда были сетевые БД и на реляционные так и не перешли.
Cache' сейчас собираются внедрять там, где живёт map-reduce, так что очень интересно может получится.

C>>А без ORM оно не нужно?

IB>Нет конечно. LL и DTO — не нужны, кеш нужен совсем в другом виде.
DTO прямо совсем не нужны? Так и собираешься dataset'ы гонять между слоями?

C>>А зачем "совсем другие"?

IB>Затем, что прикладная логика существенно многообразнее того, что нужно хранить, и меняется эта логика гораздо чаще сохраненных данных. Собственно с чего и начали — это фундаментальная разница, между собственно данными и их интерпретацией в конкретном юзкейсе конкретного приложения. "Data != Object" (c)
Ну и причём тут ORM? В объектах, с которыми работает ORM логики быть не должно. Так что пусть себе меняется.
Sapienti sat!
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 22:19
Оценка:
Здравствуйте, Gaperton, Вы писали:

G> Я говорю конкретно об их BigTable, который не слишком сильно привязан к специфике их софта.

Насколько я понимаю, таки привязано...

G>Во-первых, не только для отчетов.

Тем более...

G> На практике — они гораздо более быстрые за счет существенно лучшей масштабируемости.

К сожалению, это далеко не всегда эквивалентная замена.

G>1) Апгрейд схемы БД при изменении версии.

G>2) Репликация изменений схемы БД.
Вот это круто, если оно это умеет при относительно небольшой плате за производительность, то весьма интересно.

G>3) "Нормализация" и понижение производительности из-за обилия операций join. В CouchDB как ключ, так и значения могут быть составным типом произвольной сложности (это произвольные JSON-объекты). Это касается и "table-oreinted view" в том числе.

Ну, так и в RBD можно BLOB записать, а как только нам от BLOB-а нужны подробности — здравствуй join.

G>4) Реляционная модель — это не та модель, в которой удобно работать в твоей проге.

Собственно, мой поинт в этой дискуссии ровно в том, что на данный момент, для работы с данными, реляционная модель, таки удобнее любой другой. И лучше работать в ОО с реляционной моделью, чем пытаться из данных строить графы объектов. Другое дело, что идеальным решением может быть что-то еще, но это "что-то еще", определенно сильно смахивает на ту же реляционку.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 22:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Она отделяется ровно в той мере, в которой объекты отделены от схемы БД в ORM.

Как-то ты быстно с OODB съехал.. =)
Как я уже писал, именно по этому ORM встречаются гораздо чаще, чем OODB, но тем не менее, ORM у тебя строит вполне конкретный граф объектов, который для другого юзкейса уже не катит.

C>Иерархические БД — отличаются, слишком они примитивные. Сетевые БД — уже ближе, да.

Иными словами — никакой форы не было.

C>Cache' сейчас собираются внедрять там, где живёт map-reduce, так что очень интересно может получится.

Это последние судороги? =)

C>DTO прямо совсем не нужны? Так и собираешься dataset'ы гонять между слоями?

Причем тут датасеты?

C>Ну и причём тут ORM? В объектах, с которыми работает ORM логики быть не должно.

При том, что ORM-ом, равно как и OODB, ты пытаешься построить совершенно конкретный граф объектов, вместо того, чтобы просто использовать данные.
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[35]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.09.08 07:14
Оценка:
Здравствуйте, IB, Вы писали:

C>>У Андрея проблема в том, что с одним соединением идёт работа из нескольких потоков. Все известные БД на таком use-case'е глючат.

IB>Так с соединением или с гибернейтовской сессией?

Попрошу без инсинуаций Это не шатная ситуация! И с соединением и с сессией работает только один поток. Но если один объект вычитать из БД и передать на обработку в другие потоки (т.е. читаем в db-thread обрабатываем на пуле worker-ов), то поведение получалось непредсказуемым. В лучшем случае, если в db-thread работа с БД закончилась, то получается LazyLoadException. Тогда всё ясно. В более сложном случае, при доступе к нересолвеной LL ссылке из разных потоков происходила конкурентная работа с хиб.сессий и БД. Тут всё сложно. Может даже не быть исключений. Просто течёт память и конекшены к БД Какого-то corruption данных вроде не случалось — и на том спасибо.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.09.08 07:38
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.


Я бы сказал по другому. Там где можно применить ORM скорее всего нафиг не нужны RDB. Там где нужны преимущества предоставляемые моделью RBD вреден ORM.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 08:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

A>>Cyberax, я его превел не в контексте спора, а сам по себе. Очень правильный закон ограничивающий связность системы. Не стоит о нем забывать.

C>Чем правильный?
Самое главное что уменьшается связность системы (а особенно неочеведная связность).
Метод SomeMethod(SomeObject object): зависит только от класса SomeObject, а не от всех классов с которыми он связан. Если метод требует SomeObject то он его и использует, а не его потроха.

C>Да ещё и хватило наглости назвать это "законом".

Без комментариев.

A>>В частности закон деметры запрещает проектировать классы с вложенными коллекциями в виде: order.Items.Add(newItem) предлагая в замен order.AddItem(newItem).

C>Вот это и есть неправильно.
Почему неправильно? Тем, что класс не позволяет напрямую изменять сущности от которых зависит?

Может доведем ситуацию до абсурдной: "student.Group = newGroup"? Надеюсь с этим вопросов не возникает.
Чем же тогда принципиально отличается order.Items.Add(newItem)?

И еще:

Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

Я так понимаю ты описался, правильно? Ну зачем старосте группы метод addToAssignments? Лучше же prefect.Assignments.Add(...)


A>>P.S. Тем более никаким образом он не ограничивает запросы из двух таблиц

C>Ограничивает. Так как join двух таблиц — тоже нарушение принципа Деметры.
Каким образом? Ты уверен, что правильно его понял?

C>И вообще, можешь показать мне как будет выглядеть "деметрированый" метод, который будет переводить студента в группу к другому студенту?

Такого метода не будет! Во всяком случае этот метод будет делегировать работу более общему методу который переводит студента в другую группу:
void TranferStudentToOtherStudentGroup(Student transferingStudent, Student studentToWhoseGroupTransfering)
{
    _groupHelper.ChangeStudentGroup(transferingStudent, student.Group);
}


СУВ, Aikin
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 08:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Кстати, он ещё и противоречит принципу, что методы класс должны заниматься только тем, что требует доступа к его приватным данным.

A>>1) Каким это образом? Тем, что он не запрещает?
C>Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.
1) Вы не ответили на вопрос. Как избыточность/неизбыточность соотносится с "методы класс должны заниматься только тем, что требует доступа к его приватным данным"?
2) Ага, и методы get/set_something тоже избыточны, раз есть публичное поле? Ню-ню.

A>>2) Что это за принцип-то такой? Не мог бы ты полнее его озвучить?

C>Да очень простой принцип, неоднократно обсуждали в форуме по архитектуре. См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html (правда, Фаулер считает это антипаттерном).
А, ну если так. То почему это плохо? Интересно.

RichDomainModel противоречит AnemicDomainModel. И что? Это два разных подхода. Они диаметрально противоположны. Что, блин, в этом плохого?


Кроме того Закон Деметры НЕ противоречит тому, что

методы класс должны заниматься только тем, что требует доступа к его приватным данным

.
Опровергните меня, если уж я не понимаю.

СУВ, Aikin
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 08:39
Оценка:
Здравствуйте, Aikin, Вы писали:

C>>Чем правильный?

A>Самое главное что уменьшается связность системы (а особенно неочеведная связность).
Зато увеличивает количество мусора, затрудняющего понимание этой системы.

A>Метод SomeMethod(SomeObject object): зависит только от класса SomeObject, а не от всех классов с которыми он связан. Если метод требует SomeObject то он его и использует, а не его потроха.

Дойдём до максимума — нафиг нам тогда все ассоциации между объектами, если все методы каждого объекта зависят только от своих данных?

C>>Вот это и есть неправильно.

A>Почему неправильно? Тем, что класс не позволяет напрямую изменять сущности от которых зависит?
Да.

A>Может доведем ситуацию до абсурдной: "student.Group = newGroup"? Надеюсь с этим вопросов не возникает.

Почему "до абсурдной"? Оно даже вполне нормально будет работать.

A>Чем же тогда принципиально отличается order.Items.Add(newItem)?

Ничем особым.

A>И еще:

A>

Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

A>Я так понимаю ты описался, правильно? Ну зачем старосте группы метод addToAssignments? Лучше же prefect.Assignments.Add(...)
Да, так лучше. Но это мелочи.

C>>Ограничивает. Так как join двух таблиц — тоже нарушение принципа Деметры.

A>Каким образом? Ты уверен, что правильно его понял?
Да. Каждый класс должен работать только со своими данными. А если мы делаем join по цепочке на несколько таблиц — уже интересно получается.

C>>И вообще, можешь показать мне как будет выглядеть "деметрированый" метод, который будет переводить студента в группу к другому студенту?

A>Такого метода не будет! Во всяком случае этот метод будет делегировать работу более общему методу который переводит студента в другую группу:
Вот в этом и проблема.

A>
void TranferStudentToOtherStudentGroup(Student transferingStudent, Student studentToWhoseGroupTransfering)
A>{
A>    _groupHelper.ChangeStudentGroup(transferingStudent, student.Group);
A>}

Вот таких методов из одной строки будет очень много, а их выразительность будет весьма низкой. Вывод: и нафиг оно нужно?

Тут я согласен — если действие требует нескольких скоординированых операций, то его стоит выносить в хэлперы. А вот однострочные методы — ну их нафиг.
Sapienti sat!
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 10:20
Оценка:
Здравствуйте, Cyberax, Вы писали:

A>>Самое главное что уменьшается связность системы (а особенно неочеведная связность).

C>Зато увеличивает количество мусора, затрудняющего понимание этой системы.
Голословно.

A>>Метод SomeMethod(SomeObject object): зависит только от класса SomeObject, а не от всех классов с которыми он связан. Если метод требует SomeObject то он его и использует, а не его потроха.

C>Дойдём до максимума — нафиг нам тогда все ассоциации между объектами, если все методы каждого объекта зависят только от своих данных?
Каким образом у тебя это получилось? Не могу проследить логики.
Закон Деметры не запрещает вызывать методы переданного объекта результатом которых является связанный объект, он всего лишь запрещает вызывать методы этого объекта.

C>>>Вот это и есть неправильно.

A>>Почему неправильно? Тем, что класс не позволяет напрямую изменять сущности от которых зависит?
C>Да.
Почему? (неужели сложно сразу ответить на ворос? Ты ведь знаешь, что я его задам.)

A>>Может доведем ситуацию до абсурдной: "student.Group = newGroup"? Надеюсь с этим вопросов не возникает.

C>Почему "до абсурдной"? Оно даже вполне нормально будет работать.
Да, до тех пор, пока модуль подсчета стипендии не поменяет группу студента, а ты без детального анализа даже не сможешь найти место где это произошло.

A>>И еще:

A>>

Чаще всего для LL характерен такой код "someStudent.getParentGroup().getGroupPrefect().addToAssignments(...)".

A>>Я так понимаю ты описался, правильно? Ну зачем старосте группы метод addToAssignments? Лучше же prefect.Assignments.Add(...)
C>Да, так лучше. Но это мелочи.
Почему же ты предлагаешь заведомо худший вариант?

C>>>Ограничивает. Так как join двух таблиц — тоже нарушение принципа Деметры.

A>>Каким образом? Ты уверен, что правильно его понял?
C>Да. Каждый класс должен работать только со своими данными. А если мы делаем join по цепочке на несколько таблиц — уже интересно получается.
Ну где там цепочка? Две джоинимые таблицы абсолютно равнозначны с точки зрения входных данных.
Хотя я не уверен, что Закон Деметры приминим к SQL. Я, если честно, не могу понять что же в SQL входные параметры, а что тело "метода", ...

C>>>И вообще, можешь показать мне как будет выглядеть "деметрированый" метод, который будет переводить студента в группу к другому студенту?

A>>Такого метода не будет! Во всяком случае этот метод будет делегировать работу более общему методу который переводит студента в другую группу:
C>Вот в этом и проблема.
В чем проблема?
В том, что за изменение группы студентам будет отвечать ОДИН метод вместо десятка мелкоспециализированных ("переводить студента в группу к другому студенту")?

A>>
void TranferStudentToOtherStudentGroup(Student transferingStudent, Student studentToWhoseGroupTransfering)
A>>{
A>>    _groupHelper.ChangeStudentGroup(transferingStudent, student.Group);
A>>}

C>Вот таких методов из одной строки будет очень много, а их выразительность будет весьма низкой. Вывод: и нафиг оно нужно?
Заметь, это ты попросил метод "который будет переводить студента в группу к другому студенту". То что метод получился однострочным лишь следствие твоей задачи, а не чего-то еще.

СУВ, Aikin
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 11:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Зато увеличивает количество мусора, затрудняющего понимание этой системы.

S>Дело не в количестве мусора. Всё как раз наоборот — если у тебя есть некий граф объектов, то в нем некоторые связи являются избыточными с точки зрения транзитивного замыкания. Принцип Деметеры рекомендует свести граф зависимостей к остовному дереву. Очевидным образом, мы уменьшаем количество мусора (коим являются с точки зрения этого принципа "лишние" связи).
Да нифига не рекомендует. Мне точно так же может потребоваться работа с объектами, скажем , двумя уровнями ниже текущего. И то что они все образуют дерево — тут ничего не решает.

C>>Дойдём до максимума — нафиг нам тогда все ассоциации между объектами, если все методы каждого объекта зависят только от своих данных?

S>Максимум, до которого можно дойти без потери транзитивного замыкания — это остовное дерево.
Остовное дерево — оно в реальной жизни не живёт. Циклы встречаются слишком часто.

Да и причём оно здесь вообще?

S> Всегда смешно, когда правила из одной культуры переносят на другую. В join не участвуют никакие классы. Границы декомпозиции проходят совсем в других местах.

Ну вот чем отличается вот это:
select pr.id from prefect pr
inner join group grp on pr.parent_group=grp.id
inner join student st on st.parent_group=grp.id
where st.id=?


От вот этого:
Prefect pr=someStudent.getParentGroup().getGroupPrefect();

?

Ну кроме того, что мне потребовалась одна простая строчка там, где тебе придётся писать кучу SQL-кода (или LINQ-кода, не суть важно).

И почему "закон" Деметры действует в одном случае, но не действует в другом?
Sapienti sat!
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 11:52
Оценка:
Здравствуйте, Aikin, Вы писали:

A>>>Самое главное что уменьшается связность системы (а особенно неочеведная связность).C>>Зато увеличивает количество мусора, затрудняющего понимание этой системы.

A>Голословно.
Как и весь "закон" Деметры.

C>>Почему "до абсурдной"? Оно даже вполне нормально будет работать.

A>Да, до тех пор, пока модуль подсчета стипендии не поменяет группу студента, а ты без детального анализа даже не сможешь найти место где это произошло.
Точно так же модуль подсчёта стипендии может выполнить "delete from student" и забыть добавить "where". Причём случай с модулем подсчёта стипендий в моём примере отлаживается элементарно — просто смотрим все точки использования метода setParentGroup() (ну или все точки записи свойства, если это C#).

A>>>Я так понимаю ты описался, правильно? Ну зачем старосте группы метод addToAssignments? Лучше же prefect.Assignments.Add(...)

C>>Да, так лучше. Но это мелочи.
A>Почему же ты предлагаешь заведомо худший вариант?
Простая ошибка. Что ты ожидаешь от примера, написанного в браузере?

A>Ну где там цепочка? Две джоинимые таблицы абсолютно равнозначны с точки зрения входных данных.

A>Хотя я не уверен, что Закон Деметры приминим к SQL. Я, если честно, не могу понять что же в SQL входные параметры, а что тело "метода", ...
Задам тот же вопрос, что и Синклеру.

В чём отличие вот этого кода:
select pr.id from prefect pr
inner join group grp on pr.parent_group=grp.id
inner join student st on st.parent_group=grp.id
where st.id=?


От вот этого:
Prefect pr=someStudent.getParentGroup().getGroupPrefect();

?

A>В том, что за изменение группы студентам будет отвечать ОДИН метод вместо десятка мелкоспециализированных ("переводить студента в группу к другому студенту")?

Этих "одних методов" в итоге набираются огромные толпы. Я это ВИДЕЛ своими глазами на системе, где так приходилось делать из-за технических ограничений.

Потом появляются методы TransferIfStudentIsLocal, TransferWithoutReissuingZachetka.
Sapienti sat!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 11:59
Оценка:
Здравствуйте, Aikin, Вы писали:

C>>Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.

A>1) Вы не ответили на вопрос. Как избыточность/неизбыточность соотносится с "методы класс должны заниматься только тем, что требует доступа к его приватным данным"?
Тем и относится. Добавление в коллекцию не требует доступа к приватным данным, следовательно этих методов быть не должно.

A>2) Ага, и методы get/set_something тоже избыточны, раз есть публичное поле? Ню-ню.

Тут другая ситуация, get/set методы — это способ организации свойств. Которые ведут себя, как ни странно, почти как простое поле класса.

Свойства, в свою очередь, — это простой способ организовать специальную обработку установления полей.

В языках, где можно перехватывать доступ к "полю" (Scala, скажем), get/set методы становятся избыточными.

C>>Да очень простой принцип, неоднократно обсуждали в форуме по архитектуре. См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html (правда, Фаулер считает это антипаттерном).

A>А, ну если так. То почему это плохо? Интересно.
Это не анти-паттерн, но Фаулер его таковым считает.

A>RichDomainModel противоречит AnemicDomainModel. И что? Это два разных подхода. Они диаметрально противоположны. Что, блин, в этом плохого?

Обсуждалось в форуме по Архитектуре, поищи там.

A>Кроме того Закон Деметры НЕ противоречит тому, что

методы класс должны заниматься только тем, что требует доступа к его приватным данным

.

A>Опровергните меня, если уж я не понимаю.
Кстати! Кто тебе сказал, что строка "student.getParentGroup().getPrefect()" находится в классе Student?
Sapienti sat!
Re[36]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 12:02
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IB>>Так с соединением или с гибернейтовской сессией?

ANS>Попрошу без инсинуаций Это не шатная ситуация! И с соединением и с сессией работает только один поток. Но если один объект вычитать из БД и передать на обработку в другие потоки (т.е. читаем в db-thread обрабатываем на пуле worker-ов), то поведение получалось непредсказуемым. В лучшем случае, если в db-thread работа с БД закончилась, то получается LazyLoadException. Тогда всё ясно.
Ну вот эффективно и получается, что у тебя идёт параллельная работа над графом объектов из многих сессий.

ANS>В более сложном случае, при доступе к нересолвеной LL ссылке из разных потоков происходила конкурентная работа с хиб.сессий и БД. Тут всё сложно. Может даже не быть исключений. Просто течёт память и конекшены к БД Какого-то corruption данных вроде не случалось — и на том спасибо.

Я же тебе говорил вроде как это пофиксить Делаем свой LazyLoadingHandler и в нём делегируем вызовы в db-поток (или хотя ставим синхронизацию на обращение к сессии).

Как вариант — отключить LL и смотреть где выпадет.
Sapienti sat!
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 12:02
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

C>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

ANS>Я бы сказал по другому. Там где можно применить ORM скорее всего нафиг не нужны RDB. Там где нужны преимущества предоставляемые моделью RBD вреден ORM.
Так на практике бывает нужно и то, и другое. Возможности RDB нужны для построения отчётов и сложных запросов, а ORM — для построения логики.
Sapienti sat!
Re[29]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 12:07
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ты думаешь это от хорошей жизни так сделали? У каждого потока есть своя сессия, как полагается. Только скорость обработки запроса была упала в 6 раз по сравнению с без гибернейта в лучшем случае, до совершенно несуразных цифр там, где доля работы с БД была побольше. И потребление памяти на некоторых задачах подскочило с 2-х гиг до 16 (большой привет каждому треду со своим графом объектов).

Значит надо разбивать задачу на куски и выполнять куски по-отдельности.

ANS>Естественно, это проблема не ORM вообще, а проблема неоптимальности конкретного Hibernate. Проблема ORM в невозможности без проблем работу распаралелить или закешировать.

"Проблема ORM" или "Проблема Hibernate"?

ANS>Попытки что-то закешировать приводили поначалу к слабоуловимым ошибкамт(совершенно разным и феерическим), а теперь привела к необходимости превентивно резолвить все LL ссылки. Т.е. на всякий случай приходится грузить дерево объектов, потому что не ясно какой кусок, когда и кому понадобится.

Так ведь и без ORM пришлось бы все данные загружать, так как LL бы не было в принципе. В чём разница?
Sapienti sat!
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 12:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Почему "до абсурдной"? Оно даже вполне нормально будет работать.

A>>Да, до тех пор, пока модуль подсчета стипендии не поменяет группу студента, а ты без детального анализа даже не сможешь найти место где это произошло.
C>Точно так же модуль подсчёта стипендии может выполнить "delete from student" и забыть добавить "where". Причём случай с модулем подсчёта стипендий в моём примере отлаживается элементарно — просто смотрим все точки использования метода setParentGroup() (ну или все точки записи свойства, если это C#).
В том-то и дело, что это поле, а не свойство! Свойство == метод. В отличии от него поле допускает безконтрольное изменение объекта. Так же как и anObject.Collection.Add(...)

A>>Ну где там цепочка? Две джоинимые таблицы абсолютно равнозначны с точки зрения входных данных.

A>>Хотя я не уверен, что Закон Деметры приминим к SQL. Я, если честно, не могу понять что же в SQL входные параметры, а что тело "метода", ...
C>Задам тот же вопрос, что и Синклеру.

C>В чём отличие вот этого кода:

C>
C>select pr.id from prefect pr
C>inner join group grp on pr.parent_group=grp.id
C>inner join student st on st.parent_group=grp.id
C>where st.id=?
C>


C>От вот этого:

C>
C>Prefect pr=someStudent.getParentGroup().getGroupPrefect();
C>

C>?
Понял.
В обоих случаях нарушается Закон Деметры. В обоих вариантах код плох.

Задам тебе тот же вопрос:
Чем отличается код
select pr.id from prefect pr
inner join group grp on pr.parent_group=grp.id
inner join student st on st.parent_group=grp.id
where st.id=?

от
select pr.id from prefect pr
inner join student st on st.parent_group=pr.parent_group
where st.id=?

?

A>>В том, что за изменение группы студентам будет отвечать ОДИН метод вместо десятка мелкоспециализированных ("переводить студента в группу к другому студенту")?

C>Этих "одних методов" в итоге набираются огромные толпы. Я это ВИДЕЛ своими глазами на системе, где так приходилось делать из-за технических ограничений.
C>Потом появляются методы TransferIfStudentIsLocal, TransferWithoutReissuingZachetka.
C какой такой стати?!! Я могу, конечно, представить как такое может получитсья. Но голову на плечах все же иметь нужно
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 12:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.

A>>1) Вы не ответили на вопрос. Как избыточность/неизбыточность соотносится с "методы класс должны заниматься только тем, что требует доступа к его приватным данным"?
C>Тем и относится. Добавление в коллекцию не требует доступа к приватным данным, следовательно этих методов быть не должно.
Сама коллекция -- приватные данные. То что ее выкинули наружу -- ошибка проектирования. По-хорошему там достаточно IEnumerable и доступа по индексу, в крайнем случае коллецию нужно сделать ReadOnly. Но не выставлять ее публично всем на растерзание.

A>>2) Ага, и методы get/set_something тоже избыточны, раз есть публичное поле? Ню-ню.

C>Тут другая ситуация, get/set методы — это способ организации свойств. Которые ведут себя, как ни странно, почти как простое поле класса.
C>Свойства, в свою очередь, — это простой способ организовать специальную обработку установления полей.
C>В языках, где можно перехватывать доступ к "полю" (Scala, скажем), get/set методы становятся избыточными.
Ну и что? С чего взялось предупреждение: старайтесь не применять публичных полей, используйте свойства (.net) или геттеры/сеттеры, даже если в них идет обычное присвоение/считыание занчения?

C>>>Да очень простой принцип, неоднократно обсуждали в форуме по архитектуре. См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html (правда, Фаулер считает это антипаттерном).

A>>А, ну если так. То почему это плохо? Интересно.
C>Это не анти-паттерн, но Фаулер его таковым считает.
Замечательно. Сам сослался на Фаулера, сам его обругал. А я оказался неправ

A>>RichDomainModel противоречит AnemicDomainModel. И что? Это два разных подхода. Они диаметрально противоположны. Что, блин, в этом плохого?

C>Обсуждалось в форуме по Архитектуре, поищи там.
Что именно почитать? Что это два разных подхода? Так я это сам знаю.
Ты на какой вопрос отвечал?

A>>Кроме того Закон Деметры НЕ противоречит тому, что

методы класс должны заниматься только тем, что требует доступа к его приватным данным

.

A>>Опровергните меня, если уж я не понимаю.
C>Кстати! Кто тебе сказал, что строка "student.getParentGroup().getPrefect()" находится в классе Student?
Никто. Вот только кто тебе сказал, что я так считаю?
Re[37]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.09.08 12:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я же тебе говорил вроде как это пофиксить Делаем свой LazyLoadingHandler и в нём делегируем вызовы в db-поток (или хотя ставим синхронизацию на обращение к сессии).


Хе-хе — я забыл уже Может к этому и вернусь. Как локальное решение для одного места чтения данных — мне подойдёт, но идея распространить на всё приложение мне не нравится. Да. Нужно подумать.

C>Как вариант — отключить LL и смотреть где выпадет.


Так и делаем. Не надёжно это
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[30]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.09.08 13:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

ANS>>Естественно, это проблема не ORM вообще, а проблема неоптимальности конкретного Hibernate. Проблема ORM в невозможности без проблем работу распаралелить или закешировать.

C>"Проблема ORM" или "Проблема Hibernate"?

Проблема скорости — проблема Хиба, проблема с тем, что в каждом потоке нужно вычитывать свои данные — проблема ORM вообще. А вычитывать LL в отдельной транзакции (как в ORM с поэтическим названием Ebean) мне не нравится по транзакционным точкам зрения.

ANS>>Попытки что-то закешировать приводили поначалу к слабоуловимым ошибкамт(совершенно разным и феерическим), а теперь привела к необходимости превентивно резолвить все LL ссылки. Т.е. на всякий случай приходится грузить дерево объектов, потому что не ясно какой кусок, когда и кому понадобится.

C>Так ведь и без ORM пришлось бы все данные загружать, так как LL бы не было в принципе. В чём разница?

Найн. Сейчас приходится грузить все данные по любому на всякий случай. Так как узнать где какие данные используются можно только эксперементально
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 13:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В чём отличие вот этого кода:

C>
C>select pr.id from prefect pr
C>inner join group grp on pr.parent_group=grp.id
C>inner join student st on st.parent_group=grp.id
C>where st.id=?
C>


C>От вот этого:

C>
C>Prefect pr=someStudent.getParentGroup().getGroupPrefect();
C>

C>?

Понял в чем дело! ИМХО, ты неправильно используешь join. Он создан для объединения таблиц, а ты используешь его для отсева данных.
select pr.id from prefect
    where pr.parent_group = (select st.parent_group from student st where id = ?)

Вот этот запрос непротиворечит Закону Деметры.
Другой вопрос применим ли он к SQL. Ведь наличие "скобочек" не означает, что внутренний селект стал другой функцией.

P.S. То что оба запроса будут преобразованы в один и тот же план выполнения -- заслуга того что оптимизации оперции join разработчики БД отдали много времени.
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 13:08
Оценка:
Здравствуйте, Aikin, Вы писали:

A>В том-то и дело, что это поле, а не свойство! Свойство == метод. В отличии от него поле допускает безконтрольное изменение объекта. Так же как и anObject.Collection.Add(...)

А часто контроль-то нужен? Мне вот контроль нужен исключительно редко. Get/set методы делают из-за того, что сложно проводить рефакторинг кода, использующего прямой доступ к полям, когда специальные действия всё-таки понадобятся.

В языках, где можно нормально перехватывать доступ к полям при необходимости — методы get/set не нужны.

A>Понял.

A>В обоих случаях нарушается Закон Деметры. В обоих вариантах код плох.
В топку тогда "закон", мешающий делать нужные вещи.

A>Задам тебе тот же вопрос:

A>Чем отличается код
A>
A>select pr.id from prefect pr
A>inner join group grp on pr.parent_group=grp.id
A>inner join student st on st.parent_group=grp.id
A>where st.id=?
A>

A>от
A>
A>select pr.id from prefect pr
A>inner join student st on st.parent_group=pr.parent_group
A>where st.id=?
A>

A>?
Ничем, это просто другая форма записи. Надо было более хитрое отношение просто сделать, чтоб так переписать не получилось.

C>>Потом появляются методы TransferIfStudentIsLocal, TransferWithoutReissuingZachetka.

A>C какой такой стати?!! Я могу, конечно, представить как такое может получитсья. Но голову на плечах все же иметь нужно
Что значит "с какой-такой стати"? Оно так и нужно бывает, в итоге. Хотя пример со студентом и зачёткой, конечно, натянутый.
Sapienti sat!
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 13:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

A>>В том-то и дело, что это поле, а не свойство! Свойство == метод. В отличии от него поле допускает безконтрольное изменение объекта. Так же как и anObject.Collection.Add(...)

C>А часто контроль-то нужен? Мне вот контроль нужен исключительно редко.
Если это не тупой контейнер, то да.

C>Get/set методы делают из-за того, что сложно проводить рефакторинг кода, использующего прямой доступ к полям, когда специальные действия всё-таки понадобятся.

То же самое относится к коллекциям.

A>>Понял.

A>>В обоих случаях нарушается Закон Деметры. В обоих вариантах код плох.
C>В топку тогда "закон", мешающий делать нужные вещи.
Продолжу: "...нужным мне способом".


C>>>Потом появляются методы TransferIfStudentIsLocal, TransferWithoutReissuingZachetka.

A>>C какой такой стати?!! Я могу, конечно, представить как такое может получитсья. Но голову на плечах все же иметь нужно
C>Что значит "с какой-такой стати"? Оно так и нужно бывает, в итоге. Хотя пример со студентом и зачёткой, конечно, натянутый.
Я спрашиваю с какой стати появляются толпы методов TransferStudentXYZ()?
Кроме того, даже если они появятся, то они будут локализованы "в своем болоте" и использовать внутри себя один единственный метод переводящий студента из одной группы в другую.



А вообще, Cyberax, не хочешь -- не используй этот закон. Что я к тебе привязался

Всего хорошего.
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 13:37
Оценка:
Здравствуйте, Aikin, Вы писали:

C>>А часто контроль-то нужен? Мне вот контроль нужен исключительно редко.

A>Если это не тупой контейнер, то да.
А для чего? Просто интересно так.

C>>Get/set методы делают из-за того, что сложно проводить рефакторинг кода, использующего прямой доступ к полям, когда специальные действия всё-таки понадобятся.

A>То же самое относится к коллекциям.
С коллекциями вообще всё плохо. Хотя бы из-за того, что в .NET/Java нет нормальных интерфейсов константных коллекций.

A>>>В обоих случаях нарушается Закон Деметры. В обоих вариантах код плох.

C>>В топку тогда "закон", мешающий делать нужные вещи.
A>Продолжу: "...нужным мне способом".
Ну так предложи лучший способ.

C>>Что значит "с какой-такой стати"? Оно так и нужно бывает, в итоге. Хотя пример со студентом и зачёткой, конечно, натянутый.

A>Я спрашиваю с какой стати появляются толпы методов TransferStudentXYZ()?
Бизнес-процессы часто бывают со сложными вариациями.

A>Кроме того, даже если они появятся, то они будут локализованы "в своем болоте" и использовать внутри себя один единственный метод переводящий студента из одной группы в другую.

Тогда этот метод сведётся к одной строчке. Вот в чём и проблема.

A>А вообще, Cyberax, не хочешь -- не используй этот закон. Что я к тебе привязался

Ну так сам же начал
Sapienti sat!
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: . Великобритания  
Дата: 22.09.08 14:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Ты забыл только упомянуть, что классический SQL — он не Turing-complete. ОЧЕНЬ не Turing-complete.

S>Классический SQL — вообще в некотором роде фикция, т.к. он опирается на скалярные функции, набор которых — implementation-specific. А вообще, вроде бы должен быть turing-complete. Ведь достаточно иметь ноль, инкремент, и выбор N-го аргумента
Нет, совсем нет. Ещё оператор примитивной рекурсии забыл.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 22.09.08 14:19
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>А часто контроль-то нужен? Мне вот контроль нужен исключительно редко.

A>>Если это не тупой контейнер, то да.
C>А для чего? Просто интересно так.
Я неправильно тебя понял. Контроль-то нужен не частно, но вот отделение самой коллекции от методов ее изменения я практикую почти всегда (исключая "тупые контейнеры").

C>>>Get/set методы делают из-за того, что сложно проводить рефакторинг кода, использующего прямой доступ к полям, когда специальные действия всё-таки понадобятся.

A>>То же самое относится к коллекциям.
C>С коллекциями вообще всё плохо. Хотя бы из-за того, что в .NET/Java нет нормальных интерфейсов константных коллекций.
В 80% достаточно IEnumeranble, в остальных случаях написать кастомный интерфейс не сложно.

A>>А вообще, Cyberax, не хочешь -- не используй этот закон. Что я к тебе привязался

C>Ну так сам же начал
Я обратил внимание и даже не хотел спорить, но ты меня вынудил
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 14:28
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Понял в чем дело! ИМХО, ты неправильно используешь join. Он создан для объединения таблиц, а ты используешь его для отсева данных.

А я что делаю? Соединяю таблицы по ключам. Самое прямое применение для join.

A>
A>select pr.id from prefect
A>    where pr.parent_group = (select st.parent_group from student st where id = ?)
A>

A>Вот этот запрос непротиворечит Закону Деметры.
Точно так же противоречит, особенно если ещё один уровень введёшь. Ты просто записываешь одно и то же выражение в разных видах.

A>Другой вопрос применим ли он к SQL. Ведь наличие "скобочек" не означает, что внутренний селект стал другой функцией.

Суть от этого не меняется.
Sapienti sat!
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 22.09.08 22:11
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Проблема скорости — проблема Хиба, проблема с тем, что в каждом потоке нужно вычитывать свои данные — проблема ORM вообще.

Т.е. threadsafe ORM даже в теории невозможны?

ANS>А вычитывать LL в отдельной транзакции (как в ORM с поэтическим названием Ebean) мне не нравится по транзакционным точкам зрения.

Моё решение для твоего случая как раз идеальным будет.

C>>Так ведь и без ORM пришлось бы все данные загружать, так как LL бы не было в принципе. В чём разница?

ANS>Найн. Сейчас приходится грузить все данные по любому на всякий случай. Так как узнать где какие данные используются можно только эксперементально
Ну так что без ORM-то изменится?
Sapienti sat!
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 23.09.08 02:55
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Так вот, эта модель, "справочник-документ-отчет", отлично ложится на безсхемные базы класса map-reduce. Это просто манна небесная, от какого количества проблем она освобождает. Реляционная модель только создает ненужный гемор, как в анализе, так и в разработке.


Это всё работает до поры до времени. На небольших объёмах можно все данные вообще складывать в один блоб и не париться. Всё в XML, XML в блоб. При сегодняшних гигагерцах небольшая бухгалтерия будет летать со свистом. Всевозможные Money от майкрософта и разные квик-буки вообще никаких SQL-серверов не используют и ничего. Проблемы начинаются когда чтобы получить отчёт всё это нужно поднять в память и перемолотить, а памяти и гигагерцев не хватает.
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.09.08 04:00
Оценка:
Здравствуйте, ., Вы писали:
.>Нет, совсем нет. Ещё оператор примитивной рекурсии забыл.
Но-но, не надо тут метамодели привлекать. А то недалеко и до Зеноновых парадоксов. Вот где у нас "оператор применения оператора"? А без него непонятно, почему это мы считаем себя вправе применить рекурсию.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[32]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.09.08 07:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

ANS>>Проблема скорости — проблема Хиба, проблема с тем, что в каждом потоке нужно вычитывать свои данные — проблема ORM вообще.

C>Т.е. threadsafe ORM даже в теории невозможны?

В общем случае — да.

ANS>>А вычитывать LL в отдельной транзакции (как в ORM с поэтическим названием Ebean) мне не нравится по транзакционным точкам зрения.

C>Моё решение для твоего случая как раз идеальным будет.

Так этот случай только в нескольких точках запросов. В других местах всё должно быть как обычно. Но это проблема решаемая

C>Ну так что без ORM-то изменится?


Смотри нужно загружать на всякий случай A, B, C, D всегда. А так можно будет загружать A, B или C, D потому что будет видно, что без C, D код не компилится, а A, B не нужен. Плюс зачастую возникает неоптимальность N+1 поведения из-за способа доступа в объектной модели. Естественно решается введением прелоадинга, но такие места могут вести себя нормально при маленькой нагрузке и приводить к проблемам с масштабируемостью. Моё предположение — если бы изначально учитывался способ доступа к реляционным данным, то ряд проблем бы просто не возникало.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 23.09.08 08:19
Оценка:
Здравствуйте, mogadanez, Вы писали:

M>главное чтобы написаный код могли вместе смотреть заказчик и разработчик,

Если заказчик сам не является разработчиком, то смотреть код ему бесполезно.

M>чтобы когда я буду рядом с ним чтото править по его словам — оно понимал что происходит. чтобы цикл — девеломпент -> фидбек был минимальным.

M>увы релационные данные не способтвуют этому.
Это почему это?! Типа заказчик вполне в состоянии вкурить C#, а вот SQL ему не под силу?!
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: mogadanez Чехия  
Дата: 23.09.08 09:44
Оценка:
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, mogadanez, Вы писали:


M>>главное чтобы написаный код могли вместе смотреть заказчик и разработчик,

IB>Если заказчик сам не является разработчиком, то смотреть код ему бесполезно.

Это не так.

M>>чтобы когда я буду рядом с ним чтото править по его словам — оно понимал что происходит. чтобы цикл — девеломпент -> фидбек был минимальным.

M>>увы релационные данные не способтвуют этому.
IB>Это почему это?! Типа заказчик вполне в состоянии вкурить C#, а вот SQL ему не под силу?!
скорее DSL, на крайний случай fluent-interface.
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 23.09.08 11:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Да нифига не рекомендует.

S>Как это не рекомендует?
Так. Циклические графы замечательно тоже подходят.

C>>И то что они все образуют дерево — тут ничего не решает.

S>Ты, наверное, не понял. Тебе запрещено обращаться "двумя уровнями ниже текущего". Ты будешь обращаться к "одному уровню ниже текущего", а уже он будет обращаться к своему "нижнему уровню". Это понятно?
Это понятно и нафиг не нужно. Например, при работе с древовидными структурами, где узлы однотипны.

S>Укушенные постоянно испытывают тягу к избыточному использованию промежуточных сущностей.

Ну добавь:
select pr.id, pr.name, ..., grp.id, grp.name, grp.code from prefect pr
inner join group grp on pr.parent_group=grp.id
inner join student st on st.parent_group=grp.id
where st.id=?

Т.е. сразу загружаем нужные данные.

C>>И почему "закон" Деметры действует в одном случае, но не действует в другом?

S>Во-вторых, этот код никакого отношения к принципу Деметры не имеет, поскольку здесь нет разыменования ссылок. Совсем.
Есть. Точно такое же, как и в student.getParentGroup().getPrefect(). Просто оно выражается по-другому — через объединения по PK.

S>Достаточно убрать where, и это вообще будет полностью симметричный относительно student и prefect запрос. Никто из них ни к кому не обращается.

Ну так берём коллекцию AllObjects — и выбираем на ней нужные объекты с помощью фильтра. То же самое получится. Только вот это глупо, без where мы полную фигню получим. А с where у нас симметрия моментально теряется.
Sapienti sat!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: . Великобритания  
Дата: 23.09.08 20:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

.>>Нет, совсем нет. Ещё оператор примитивной рекурсии забыл.

S>Но-но, не надо тут метамодели привлекать. А то недалеко и до Зеноновых парадоксов. Вот где у нас "оператор применения оператора"? А без него непонятно, почему это мы считаем себя вправе применить рекурсию.
Это к чему? Чтобы система стала turing complete, "ноль, инкремент, и выбор N-го аргумента" не хватит, нужно ещё, например, оператор примитивной рекурсии добавить — получится ПРФ. Классический sql не обладает turing-completeness, скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 24.09.08 02:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну добавь:

C>
C>select pr.id, pr.name, ..., grp.id, grp.name, grp.code from prefect pr
C>inner join group grp on pr.parent_group=grp.id
C>inner join student st on st.parent_group=grp.id
C>where st.id=?
C>

C>Т.е. сразу загружаем нужные данные.
Вот! Вот!

S>>Во-вторых, этот код никакого отношения к принципу Деметры не имеет, поскольку здесь нет разыменования ссылок. Совсем.

C>Есть. Точно такое же, как и в student.getParentGroup().getPrefect(). Просто оно выражается по-другому — через объединения по PK.
Во-первых, не точно такое же. Перечитай свой запрос. Ему вообще нет никакого аналога в ООП — мы отобразили некий граф кортежей в список кортежей. Это атомарная операция, как, к примеру, умножение матриц. Или ты полагаешь, что принцип Деметры запрещает писать F = A * B * C в одной строке?

C>Ну так берём коллекцию AllObjects — и выбираем на ней нужные объекты с помощью фильтра. То же самое получится. Только вот это глупо, без where мы полную фигню получим. А с where у нас симметрия моментально теряется.

Это иллюзия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 24.09.08 06:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Есть. Точно такое же, как и в student.getParentGroup().getPrefect(). Просто оно выражается по-другому — через объединения по PK.

S> Во-первых, не точно такое же. Перечитай свой запрос. Ему вообще нет никакого аналога в ООП — мы отобразили некий граф кортежей в список кортежей.
student.getParentGroup().getPrefect() — это тоже операция над графом объектов, взятие объекта по заданной оси. Я могу это записать на декларативном языке JDOM: "jdom.query("student/parentGroup/prefect", student).execute()". То что эта операция записывается в виде вызова обычных методов — ну уж извините, просто используем фичи языка.

S>Это атомарная операция, как, к примеру, умножение матриц. Или ты полагаешь, что принцип Деметры запрещает писать F = A * B * C в одной строке?

Ну да, мой пример — прямой аналог A * B * C.

Так что если оно нарушает этот принцип, то и SQL-запрос его будет нарушать.

C>>Ну так берём коллекцию AllObjects — и выбираем на ней нужные объекты с помощью фильтра. То же самое получится. Только вот это глупо, без where мы полную фигню получим. А с where у нас симметрия моментально теряется.

S>Это иллюзия.
Где?
Sapienti sat!
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 24.09.08 10:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

JDOM: "jdom.query("student/parentGroup/prefect", student).execute()".
Молодец, правильно мыслишь. Как только ты так сделаешь, ты обойдешь принцип Деметры.
C> То что эта операция записывается в виде вызова обычных методов — ну уж извините, просто используем фичи языка.
А если операция будет записана в виде ассемблерной вставки, мы по прежнему будем говорить о применимости принципа Деметры?

C>Ну да, мой пример — прямой аналог A * B * C.

C>Так что если оно нарушает этот принцип, то и SQL-запрос его будет нарушать.
Я думаю, самое время тебе перечитать определение принципа Деметры и попытаться понять разницу в применениях, и соотношение этого принципа с границами инкапсуляции.

S>>Это иллюзия.

C>Где?
Что симметрия теряется.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[29]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 24.09.08 10:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>JDOM: "jdom.query("student/parentGroup/prefect", student).execute()".

S>Молодец, правильно мыслишь. Как только ты так сделаешь, ты обойдешь принцип Деметры.
А если я JDOM встрою в язык:
var prefect=student/parentGroup/prefect

?

Где границу проводить-то будем?

S> А если операция будет записана в виде ассемблерной вставки, мы по прежнему будем говорить о применимости принципа Деметры?

Да, этот принцип точно так же применим, и точно так же контр-продуктивен.

C>>Так что если оно нарушает этот принцип, то и SQL-запрос его будет нарушать.

S>Я думаю, самое время тебе перечитать определение принципа Деметры и попытаться понять разницу в применениях, и соотношение этого принципа с границами инкапсуляции.
Вот я и говорю — принцип неприменим нормально ни к чему.

C>>Где?

S>Что симметрия теряется.
Теряется. Мы начинаем объединение с одного конца.
Sapienti sat!
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.09.08 13:28
Оценка:
Здравствуйте, ., Вы писали:

.>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.


Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет. Просто реальные сервера ограничивают рекурсию вглубь вполне конкретным небольшим числом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1096>>
AVK Blog
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.09.08 13:28
Оценка:
Здравствуйте, Aikin, Вы писали:

A>А вообще, Cyberax, не хочешь -- не используй этот закон. Что я к тебе привязался


Так всегда бывает. Я не знаю ни одного программиста, которому, когда укажешь на то, что он багу наплодил или сделал кривой дизайн, не бросился бы доказывать обратное. Вопрос только в степени этого явления. Некоторые (я не Cyberax имею ввиду) упираются рогом до последнего, переходя на демагогию, но свою неправоту не признают.
... << RSDN@Home 1.2.0 alpha 4 rev. 1096>>
AVK Blog
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 25.09.08 14:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Так всегда бывает.

Я хочу думать, что а не такой // хотя развернув мысль, понял что не от каждого я бы "стерпел" Надо работать над собой

AVK>Я не знаю ни одного программиста, которому, когда укажешь на то, что он багу наплодил или сделал кривой дизайн, не бросился бы доказывать обратное. Вопрос только в степени этого явления. Некоторые (я не Cyberax имею ввиду) упираются рогом до последнего, переходя на демагогию, но свою неправоту не признают.

Я старался, бегал с идеей, ночами не спал, а тут какой-то "хмырь с соседнего совхоза" говорит что я НЕПРАВ




Да, такое почти всегда и бывает.
Причем очень важно кто именно укажет человеку на пробел. От одних людей мы сносим поучения, другим благодарны за это, а от третьх просто не терпим их.
Вот если бы про LoD упомянул ты или Синклер, или еще кто из "авторитетов", то Сайберекс прислушался и, возможно, даже согласился, но обычный участник...
(Кста, c Иваном, ИМХО, было бы то же что со мной, так с ним был жаркий спор...)

СУВ, Aikin
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 25.09.08 14:15
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Так всегда бывает. Я не знаю ни одного программиста, которому, когда укажешь на то, что он багу наплодил или сделал кривой дизайн, не бросился бы доказывать обратное. Вопрос только в степени этого явления. Некоторые (я не Cyberax имею ввиду) упираются рогом до последнего, переходя на демагогию, но свою неправоту не признают.

Я иногда признаю, что был неправ Но тут я готов спорить (с примерами!) до конца.
Sapienti sat!
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: . Великобритания  
Дата: 25.09.08 22:51
Оценка:
Здравствуйте, AndrewVK, Вы писали:

.>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.

AVK>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
Я имел в виду классический SQL (выросший из реляционной алгебры), в духе какого-нибудь стандарта типа ANSI SQL-99. А с рекурсивным CTE — да, уже turing complete... Вроде бы, всё ещё не очень уверен ибо как я тут вспомнил, что даже ПРФ не turing-complete, оператора примитивной рекурсии недостаточно, ещё нужен оператор минимизации.

AVK>Просто реальные сервера ограничивают рекурсию вглубь вполне конкретным небольшим числом.

И это именно ограничение языка, а не серверов, ибо в том смысле какой ты имеешь в виду все языки не turing-complete, т.к. мы всегда имеем какие-то ограничения ресуров, хотя бы количество атомов во Вселенной
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS