Взаимодействие с Базой Данных из 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: Взаимодействие с Базой Данных из 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
От: kuj  
Дата: 08.09.08 09:53
Оценка: +1
Здравствуйте, z3d, Вы писали:

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


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


Вообще-то EF есть в поставке VS2008 SP1.
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: Взаимодействие с Базой Данных из 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[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 08.09.08 11:24
Оценка: +2
Здравствуйте, Аноним, Вы писали:


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


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


Скажу что Вы плохо понимаете то о чем говорите.
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>>
Мы уже победили, просто это еще не так заметно...
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[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>>
Мы уже победили, просто это еще не так заметно...
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[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.. =))
Зачем использовать две сторонние библиотеки сомнительного качества, когда можно использовать одну, которая идет вместе со студией?
Мы уже победили, просто это еще не так заметно...
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[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[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 09.09.08 07:54
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Сильно сомневаюсь, что г-н IB имеет хоть малейшее представление о таковом.
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>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: kuj  
Дата: 09.09.08 08:17
Оценка: -2 :)
Здравствуйте, IB, Вы писали:

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

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

Нет.
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>>
Мы уже победили, просто это еще не так заметно...
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[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[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>>
Мы уже победили, просто это еще не так заметно...
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[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: Взаимодействие с Базой Данных из 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[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[3]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 15.09.08 22:36
Оценка: :)
Здравствуйте, criosray, Вы писали:

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

C> Первая версия 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[5]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 16.09.08 09:03
Оценка: :)
Здравствуйте, criosray, Вы писали:

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

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

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

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

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

Сломался?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 16.09.08 09:09
Оценка:
Здравствуйте, IB, Вы писали:


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

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

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

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

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

IB>Сломался?

Да-да, Вы правы, я сломался. Только не волнуйтесь так. Это вредно для здоровья.
Re[5]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.09.08 09:13
Оценка: -1
Здравствуйте, criosray, Вы писали:
Просто вся аргументация была уже приведена неоднократно, и даже совсем недавно. Заниматься повторением аргументов каждому новоприбывшему в топик терпения хватает не у многих.
Вкратце могу отослать к другому термину — leaky abstractions. Вот когда абстракции lazy loading и persistence ignorance становятся leaky, тут и вылезают проблемы с масштабированием и производительностью. А эти абстракции протекают легко и часто, что и делает их плохими, в отличие от, скажем, абстракции MSIL.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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 Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: criosray  
Дата: 16.09.08 13:33
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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

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

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


Во-первых, смените тон, уважаемый. Я Вас кажется не оскорблял. Во-вторых, то, что пишите Вы не имеет ничего общего с leaky abstractions. Садитесь — два.
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>>
Мы уже победили, просто это еще не так заметно...
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[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 16.09.08 19:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>У меня вообще ощущение, что если возникают проблемы с LL, то стоит посмотреть не делаем ли мы в коде слишком много лишних действий.
И с чем товарищ IB не согласен?
Sapienti sat!
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-ов скорее вредит, так как тащит кучу лишнего кода и провоцирует кривую архитектуру.
Мы уже победили, просто это еще не так заметно...
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[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.

Ага, ты, помнится, хвастался, как пол гибернейта под свою задачу переписал.
Мы уже победили, просто это еще не так заметно...
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.09.08 02:59
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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

Ты, наверное, не заметил, что Items — это OrderItems. Каждая, естественно, указывает на отдельную StockItem. И вот тут и начинаются чудеса в решете.
C>У меня вообще ощущение, что если возникают проблемы с LL, то стоит посмотреть не делаем ли мы в коде слишком много лишних действий.
Всё как раз наоборот: чтобы с LL проблем не было, придется делать лишние действия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.09.08 02:59
Оценка:
Здравствуйте, criosray, Вы писали:
C>Во-первых, смените тон, уважаемый. Я Вас кажется не оскорблял. Во-вторых, то, что пишите Вы не имеет ничего общего с leaky abstractions. Садитесь — два.
Отлично. Статью не читал, значения терминов придумываешь сам. Вместо аргументов будем, значит, фокусироваться на моем тоне. Удачи. Троллей тут игнорят.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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: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[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[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 17.09.08 06:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

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

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

S>Всё как раз наоборот: чтобы с LL проблем не было, придется делать лишние действия.
Уже ответил.
Sapienti sat!
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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[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[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: Аноним  
Дата: 17.09.08 09:02
Оценка: +3
Здравствуйте, WaSh, Вы писали:

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


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

поэтому продолжайте господа, вас приятно слушать!
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>>
Мы уже победили, просто это еще не так заметно...
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[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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 Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 18.09.08 19:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Объ

Случайно обрезалось: для того, чтобы определить какие данные нужно загрузить — часто нужна сама по себе неслабая логика. Если её делать в SQL-батчах, то её как-то придётся на SQL и записывать.

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

Блин, хотел написать 50Гб и 30-40Гб в год.
Sapienti sat!
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
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
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[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>Значит исходный посыл ошибошен, значит весь пост ошибочен.


Посыл не просто не ошибочый, а единственно возможный. Я тебе даже мог бы в подробностях рассказать как всё началось, но сначала тебе домашнее задание — найти связь между типизацией и объектной моделью
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
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[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 вспоминаешь
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
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[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[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>У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.
Каким образом создание отдельной сессии на поток позволит разобраться, кода какие данные нужны и когда они будут загружены?
Мы уже победили, просто это еще не так заметно...
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> (правда, Фаулер считает это антипаттерном).

Это исключительно проблемы Фаулера. =)
Мы уже победили, просто это еще не так заметно...
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[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.

Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.
Мы уже победили, просто это еще не так заметно...
Re[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 20.09.08 00:53
Оценка: +1
Здравствуйте, IB, Вы писали:

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

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

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

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

Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 20.09.08 05:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>У товарища ANS проблема в том, что граф объектов одновременно обходится из нескольких потоков.

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

C>Если бы каждый поток работал со своими личными объектами — такой проблемы не было бы.

Стоп — стоп. Это я что, вынужден в прикладном коде разруливать с какой сессией какой поток работает?!! Афигеть удобство.
Мы уже победили, просто это еще не так заметно...
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.

То что они существуют совершенно не означает, что это альтернатива.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 20.09.08 23:09
Оценка: -2
Здравствуйте, IT, Вы писали:

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

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

Просто так получилось.
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 сегодня нет.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
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.

Причем тут протоколы? Меня это не парит совешенно, синхронизацией пусть база занимается, у нее это получается лучше всех.
Мы уже победили, просто это еще не так заметно...
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[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[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?!
Мы уже победили, просто это еще не так заметно...
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'е глючат.

Так с соединением или с гибернейтовской сессией?
Мы уже победили, просто это еще не так заметно...
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>Сейчас — они поднимаются по хайпу, скоро будут на пике.


Если появится достойная альтернатива, то я буду только рад Мне как пользователю технологий любая конкуренция только на руку. Но пока я не вижу достойных альтернатив.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
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.

Какой?
Мы уже победили, просто это еще не так заметно...
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>С обоими.

То есть, при работе с гибернейтовской сессией, я должен следить за доступом к ней из различных потоков?
Мы уже победили, просто это еще не так заметно...
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, если в приложении, для реализации конкретного юзкейса, мне нужны совсем другие объекты?
Мы уже победили, просто это еще не так заметно...
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>Ровно так же, как ты должен следить за тем, что одно соединение с БД не используется из нескольких потоков.

Причем тут соединение? Не уворачивайся, мы уже по кругу идем, как поступают с соединением я тебе уже рассказал. Поступать так с сессией смысла не имеет, так как теряется сам смысл сессии.
Отсюда можно сделать вывод, что при работе с сессиями гибернейта, надо в ручную разруливать многопоточность, что является конкретным косяком.
Мы уже победили, просто это еще не так заметно...
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[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 19:20
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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

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

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

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

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

IB>Иными словами, пока нам производительность не критична, то можем наслаждаться гибкостью?
Примерно так. Ну и ещё имеем удобный формат для массивных map-reduce операций, на которых обычные RDB ничем не могут помочь.
Sapienti sat!
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[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[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)
Мы уже победили, просто это еще не так заметно...
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) Реляционная модель — это не та модель, в которой удобно работать в твоей проге.

Собственно, мой поинт в этой дискуссии ровно в том, что на данный момент, для работы с данными, реляционная модель, таки удобнее любой другой. И лучше работать в ОО с реляционной моделью, чем пытаться из данных строить графы объектов. Другое дело, что идеальным решением может быть что-то еще, но это "что-то еще", определенно сильно смахивает на ту же реляционку.
Мы уже победили, просто это еще не так заметно...
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, ты пытаешься построить совершенно конкретный граф объектов, вместо того, чтобы просто использовать данные.
Мы уже победили, просто это еще не так заметно...
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[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
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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[6]: Взаимодействие с Базой Данных из C# по схеме MS
От: mogadanez Чехия  
Дата: 22.09.08 21:17
Оценка: :)
ANS>> А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными.
IB>Это заблуждение, к сожалению довольно популярное. Корни его, на самом деле, проистекают из другого, еще более популярного заблуждения — интуитивно-ошибочной интерпретации понятия "ОО программа".

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

увы релационные данные не способтвуют этому.
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[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-серверов не используют и ничего. Проблемы начинаются когда чтобы получить отчёт всё это нужно поднять в память и перемолотить, а памяти и гигагерцев не хватает.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.09.08 04:00
Оценка:
Здравствуйте, ., Вы писали:
.>Нет, совсем нет. Ещё оператор примитивной рекурсии забыл.
Но-но, не надо тут метамодели привлекать. А то недалеко и до Зеноновых парадоксов. Вот где у нас "оператор применения оператора"? А без него непонятно, почему это мы считаем себя вправе применить рекурсию.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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>>
Мы уже победили, просто это еще не так заметно...
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>>
Мы уже победили, просто это еще не так заметно...
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 Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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 Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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[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>>
Мы уже победили, просто это еще не так заметно...
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
От: 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[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.08 09:26
Оценка:
Здравствуйте, ., Вы писали:

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


.>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.

AVK>>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
.>Я имел в виду классический SQL (выросший из реляционной алгебры),
Ну во-первых, классический SQL имеет очень косвенное отношение к реляционной алгебре. Это становится очевидно, если внимательно посмотреть на саму алгебру и попытаться найти общие черты с SQL. SQL построен скорее "по мотивам" реляционной алгебры, в том смысле, что в нем не было специальных навигационных операций (типичных для сетевых и иерархических СУБД руливших в момент его появления).

.> в духе какого-нибудь стандарта типа ANSI SQL-99.

Ага, как раз в нем CTE и были введены. Вообще, тут в форуме термин "ANSI SQL" часто поминают всуе, в то время как живьем этот документ видели, наверное, всего пара человек. Я вот, к примеру, в них не вхожу.

.>даже ПРФ не turing-complete, оператора примитивной рекурсии недостаточно, ещё нужен оператор минимизации.

И оператор подстановки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: . Великобритания  
Дата: 26.09.08 10:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>\.>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.

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

AVK>Вот как раз в этом стандарте CTE И появились.

что-то судя по гуглу там оно нерекурсивное.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: . Великобритания  
Дата: 26.09.08 10:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

.>>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.

AVK>>>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
.>>Я имел в виду классический SQL (выросший из реляционной алгебры),
S>Ну во-первых, классический SQL имеет очень косвенное отношение к реляционной алгебре. Это становится очевидно, если внимательно посмотреть на саму алгебру и попытаться найти общие черты с SQL. SQL построен скорее "по мотивам" реляционной алгебры, в том смысле, что в нем не было специальных навигационных операций (типичных для сетевых и иерархических СУБД руливших в момент его появления).
Да вроде один к одному (если рассматривать SELECT) — таблицы-отношения, проекции, джойны.

.>> в духе какого-нибудь стандарта типа ANSI SQL-99.

S>Ага, как раз в нем CTE и были введены. Вообще, тут в форуме термин "ANSI SQL" часто поминают всуе, в то время как живьем этот документ видели, наверное, всего пара человек. Я вот, к примеру, в них не вхожу.
В интуитивном понимании: "пересечение возможностей всех популярных СУБД".

.>>даже ПРФ не turing-complete, оператора примитивной рекурсии недостаточно, ещё нужен оператор минимизации.

S>И оператор подстановки.
Это вроде есть. Как я понимаю — это делают поздапросы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 26.09.08 10:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну во-первых, классический SQL имеет очень косвенное отношение к реляционной алгебре. Это становится очевидно, если внимательно посмотреть на саму алгебру и попытаться найти общие черты с SQL.

И чего же на экзамене по реляционной алгебре я доказывал реляционную полноту SQL тогда?
Sapienti sat!
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.08 11:22
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>И чего же на экзамене по реляционной алгебре я доказывал реляционную полноту SQL тогда?
А какое отношение это имеет к вопросу? С этой точки зрения, клиппер тоже вполне себе реляционо полный.
Это же не означает, что он построен на основе реляционной алгебры.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.08 11:27
Оценка:
Здравствуйте, ., Вы писали:

.>Да вроде один к одному (если рассматривать SELECT) — таблицы-отношения, проекции, джойны.

А, ну вот начинается. Для начала мы из всего DDL/DML начинаем рассматривать "только селект".
Затем мы увидим, что в реляционной алгебре есть несколько типов джойнов, но практически ни один из них не соответствует напрямую типам джойнов в SQL.
Оказывается, что большинству операторов РА в SQL нет прямых аналогов. А операторы, знакомые нам по SQL, в РА работают несколько по другому.

Или, нвпример, с точки зрения РА почти ничего из того, что получается в результате применения операторов SQL к таблицам, отношением не является.
Странно для языка, выросшего из реляционной алгебры, не так ли?

.>В интуитивном понимании: "пересечение возможностей всех популярных СУБД".

Это очень странное понимание. Во-первых, оно весьма аморфно (что такое популярные СУБД?), во-вторых, очевидно, что пересечение возможностей будет таки заведомо крайне убогим.

S>>И оператор подстановки.

.>Это вроде есть. Как я понимаю — это делают поздапросы.
Типа того.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 26.09.08 17:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>И чего же на экзамене по реляционной алгебре я доказывал реляционную полноту SQL тогда?

S>А какое отношение это имеет к вопросу? С этой точки зрения, клиппер тоже вполне себе реляционо полный.
S>Это же не означает, что он построен на основе реляционной алгебры.
Ну давай смотреть. В Вики перечислены следующие свойства реляционной алгебры:
1) Проекция, выборка, фильтрование, переименование — всё есть в прямом виде.
2) Объединения: натуральный джойн, тэта-джойн, outer left/right, inner join — всё тоже есть.

В итоге, SQL прекрасно представляет реляционную алгебру.
Sapienti sat!
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: . Великобритания  
Дата: 26.09.08 20:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

.>>Да вроде один к одному (если рассматривать SELECT) — таблицы-отношения, проекции, джойны.

S>А, ну вот начинается. Для начала мы из всего DDL/DML начинаем рассматривать "только селект".
И правильно, остальное чисто инженерная нашлёпка для удобства использования, не несущая теоретического смысла.

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

S>Оказывается, что большинству операторов РА в SQL нет прямых аналогов. А операторы, знакомые нам по SQL, в РА работают несколько по другому.
А подробнее? Что не так? Всё вроде есть, даже агрегатные ф-ции.

S>Или, нвпример, с точки зрения РА почти ничего из того, что получается в результате применения операторов SQL к таблицам, отношением не является.

Эээ... почему не является?

.>>В интуитивном понимании: "пересечение возможностей всех популярных СУБД".

S>Это очень странное понимание. Во-первых, оно весьма аморфно (что такое популярные СУБД?), во-вторых, очевидно, что пересечение возможностей будет таки заведомо крайне убогим.
На то и интуитивное.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 21:56
Оценка:
Здравствуйте, IT, Вы писали:

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


Проблема ОРМ-ов еще и в том, что они вместо простого отображения из системы типов СУБД в систему типов ЯП навязывают идеологию "прозрачности". Я не знаю где это зародилось, но уже в CORBA и EJB разговор велся не об отображении данных СУБД в данные ЯП, а об прозрачной персистентности данных. Я долго не мог понять, что означают слова вроде "объект живет дольше программы". Потом осознал. ОРМ-ы пытаются сохранить состояние программы, а не упрощают обработку данных в ней. Но такой подход вызывает следующие проблемы:
1. Памяти приложения недостаточно для хранения всех объектов в памяти, а значит требуется механизм виртуализации — подкачки и сбрасывания объектов из систем персистентного хранилища (исходно они не обязательно были БД).
2. ООЯ и ИЯ не имеют выразительных средств обработки массивов данных представленных в объектной форме.

Эти проблемы приводят к тому, что код написанный на базе таких персистеров становится не эффективным и громоздким.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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) и системы сменных провайдеров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 22:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

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

Под ними лежит стройная математическая модель и эффективная реализация (возможная, от части, из-за наличия мат.модели). А вот ОРМ-ы ничем подобным похвастаться не могу. Да и работают они как раз по верх тех самых "тупиковых" РБД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 22:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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


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

Вот Лисп появившийся примерно в то же время, что и Симула имел под собой стройную мат.модель — лябда-исчислений Черча — которая, в купе со списками, отлично ложится на реляционную модель. Как результат в Лисп-программах с самого начала не нужно было создавать костылей подобных ОРМ-аперам.
Не прошло и 50 лет, как это было замечено в Майкрософт и применено на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 22:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

IB>>Ну возьми реальное приложение, которое работает с данными, на кой байт тебе там полноценный граф объектов? У такой модели хорошо получается только добираться до одного элемента по индексу, но на самом-то деле нужно фильтровать, объеденять, сортировать, агрегировать, причем самым произвольным образом, а на всех этих операциях ОО сосет как промышленный пылесос, по сравнению с моделью старика Кодда. В плоть до того, что для решения таких задач в насквозь объектный C# вкрячили функциональный LINQ, так похожий на SQL, что с двух шагов не отличить.

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

У меня один вопрос. Можно? Спасибо!

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

Эдак и Оракл является ООБД, так как позволяет хранить именованные "объекты", а не не именованные — кортежи. Не так ли?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 22:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

IB>>Затем, что прикладная логика существенно многообразнее того, что нужно хранить, и меняется эта логика гораздо чаще сохраненных данных. Собственно с чего и начали — это фундаментальная разница, между собственно данными и их интерпретацией в конкретном юзкейсе конкретного приложения. "Data != Object" (c)

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

ОК. Но тогда объясни мне разницу между твоими "объектами без поведения и логики" и кортежами РБД? Не уж-то вся разница в том, что ты используешь вместо join-ов синтаксис с точкой?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 22:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее, практически весь геморрой, знакомый по RDB, отсутствует by design. Сочетание чрезвычайной простоты, и одновременно — большой гибкости. Обрати внимание, там чрезвычайно простая модель, много времени не займет. За полчаса будешь знать все. И не надо мне говорить про то, что там все запросы делаются через REST, а это медленно . К модели данных это не относится, а CouchDB демонстрирует пока только потенциал технологии.


Заметь:
1. Это технология предназначена скорее для структурированного хранения документов (т.е. конкурент XML, а не СУБД и ОРМ-ов).
2. В отличии от идеологии ОРМ-ов она так же как и SQL-СУБД использует запросы для обработки данных, а не навигацию по объектам (хотя казалось бы документы обычно представляются в виде дерева с одним корнем).
3. На сегодня это опять же не конкурент СУБД, так как она пока находится в исследовательской стадии. Посему преимущества от нее получают только исследователи, которые рискуют, так как вероятность неудачи велика.
4. Указанная реализация динамически типизирована и использует яваскрипт в качестве языка описания данных. Это вряд ли удовлетворит тех кто привык работать со статически-типизированными данными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.08 23:10
Оценка:
Здравствуйте, IB, Вы писали:

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

IB>Так ведь SQL существенно больше DSL напоминает, чем императивный шарп.

Кроме того DSL это уж точно нечто более высокоуровневое чем работа с объектами. И DSL можно навернуть как поверх ООП, так и поверх реляционных данных. DSL же будет описывать или сами данные, или их обработку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 27.09.08 09:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Под ними лежит стройная математическая модель и эффективная реализация (возможная, от части, из-за наличия мат.модели). А вот ОРМ-ы ничем подобным похвастаться не могу. Да и работают они как раз по верх тех самых "тупиковых" РБД.
Что в ORMах ты собираешься описывать теоретически? Язык запросов в той же Hibernate является реляционно полным, это несложо доказать формально.
Sapienti sat!
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 27.09.08 10:10
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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

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

VD>Спасибо!

Пожалуйста.

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

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

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

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

Да.

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

Не совсем. Обычно под ООБД понимается система, в которую объектность интегрирована. Оракул такому требованию не отвечает (если забыть на время про его объектные таблицы).
Sapienti sat!
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 27.09.08 10:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>ОК. Но тогда объясни мне разницу между твоими "объектами без поведения и логики" и кортежами РБД? Не уж-то вся разница в том, что ты используешь вместо join-ов синтаксис с точкой?
Примерно так. Ну и представление ассоциаций в виде коллекций.
Sapienti sat!
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 27.09.08 10:13
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

Другое дело, что реализации OODB могут отступать от строгой реляционной модели, например, с помощью оптимизации путей доступа к данным. Но то же самое могут делать и RDB.
Sapienti sat!
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.08 16:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

VD>>ОК. Но тогда объясни мне разницу между твоими "объектами без поведения и логики" и кортежами РБД? Не уж-то вся разница в том, что ты используешь вместо join-ов синтаксис с точкой?

C>Примерно так.

Тогда спор снова ни о чем, так как ты используешь не сам Кибернэйт, а его подмножество во многом пересекающееся с LINQ-ом (окромя того, что Кибернэйт не поддерживает интегрированных в язык, типизированных запросов).
Суть же Кибернэйта несколько шире, как я понимаю. Вот цитата из описания Кибернэйта в Википедии:
http://ru.wikipedia.org/wiki/Hibernate_(библиотека)

Основные возможности

Целью Hibernate является освобождение разработчика от значительного объёма общих задач программирования по обеспечению сохранности данных (persistence — сохранность данных после прекращения работы программы). Разработчик может начать использовать Hibernate в процессе разработки как с нуля, так и для уже существующей базы данных.

Hibernate не только заботится о связи Java классов с таблицами базы данных (и типов данных Java в типы данных SQL), но также предоставляет средства для автоматического построения запросов и извлечения данных и может значительно уменьшить время разработки, которое обычно тратится на ручное написание SQL и JDBC кода. Hibernate генерирует SQL вызовы и освобождает разработчика от ручной обработки результирующего набора данных и конвертации объектов, сохраняя приложение портируемым во все SQL базы данных.
...


Явный упор на persistence, а не на mapping. Не правда ли?
Ежу понятно, что Hibernate можно использовать и как чистый мапер, но это слишком узкое применение. И вряд ли кто-то на нем останавливается.

C>Ну и представление ассоциаций в виде коллекций.


Это и LINQ2SQL с успехом делает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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-типами (структурами и/иди кортежами), то разницы нет никакой. Ну, разве что умозрительная. А вот если мы начинаем по полной программе ООП впихивать (с его полиморфизмом и инкапсуляцией), то как раз и нарываемся на то, что ООП не содержит концепций позволяющих эффективно обрабатывать данные и принуждает к использованию неэффективного навигационного метода работы с данными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.08 16:43
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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

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

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

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


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

И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки. А вот СУБД с движком на основе ООП я почему-то не видел. Плохо смотрел?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 27.09.08 16:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

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

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

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

Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.
Sapienti sat!
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.08 17:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

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

Классы не преобразуются в кортежи никак. У классов есть:
1. Названия.
2. Иерархия наследования.
3. Полиморфизм.
4. Инкапсуляция.

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

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

Тогда это не ООБЩ, а БД со встроенным ОРМ. Думаю, не надо объяснять, что получить производительности чистой РСУБД при таком подходе не легче (читай невозможно) чем при подходе с отдельными ОРМ и СУБД?

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

C>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.

Гы. Хранение в блобах — это не СУБД. А если используется реляционный движок, то это опять таки не ООБД, а надстройка.
Да и как иначе? Ведь много раз сказано было — ООП не был рассчитан на хранение данных в БД. Нет в нем соответствующих концепций. Концепции ООП отлично работают для классов в памяти, но никак для данных в БД. Более того ООП и средств обработки данных не предоставляет. Нельзя же считать императивные циклы таковыми?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 28.09.08 07:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Что в ORMах ты собираешься описывать теоретически? Язык запросов в той же Hibernate является реляционно полным, это несложо доказать формально.


К сожалению нет NH не умеет делать join on X, где X задаешь ты сам. В некоторых случаях это не позволяет сделать нужные запросы.

Например есть две сущности Человек и Документ, одному человеку могут соответствовать несколько документов (удостоверяющих личность). Нужен список всех людей с их паспортами, если паспорта нет — null.
Хотелось бы что-то типа:

select ч.ФИО, д.Text from Человек ч left join Документ д on (д.ЧеловекИд=ч.Ид and д.ТипДокумента = ТипДокумента.Паспорт).


Я так и не смог решить задачу с помощью HQL Есть идеи?
... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 28.09.08 09:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Классы не преобразуются в кортежи никак. У классов есть:

VD>1. Названия.
У элементов кортежей в реляционной алгебре (см. операция RENAME) они тоже есть. Далее просто вводим название класса как alias для определённого набора названий кортежей.

VD>2. Иерархия наследования.

Отображается на кортежи (дискриминатором, join-таблицами).

VD>3. Полиморфизм.

Методы мы исключаем из рассмотрения.

VD>4. Инкапсуляция.

Аналогично, это требование элементарно удовлетворяется, если ORM имеет тот же доступ, что и члены самого класса.

C>>Так и получается.

VD>Тогда это не ООБЩ, а БД со встроенным ОРМ. Думаю, не надо объяснять, что получить производительности чистой РСУБД при таком подходе не легче (читай невозможно) чем при подходе с отдельными ОРМ и СУБД?
Тут вопросы не в теории, а в практике. L2-кэш в ORMах сейчас повторяет внутренние кэши в БД, да ещё руками приходится следить за его когерентностью. Имело бы смысл его интегрировать в саму БД, например. Ну и так далее...

C>>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.

VD>Гы. Хранение в блобах — это не СУБД.
Нет, это СУБД, просто не реляционная.

VD>А если используется реляционный движок, то это опять таки не ООБД, а надстройка.

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

Если хочешь почитать теоретически выкладки о том, что я говорю, то почитай "Foundation for Object Relational Databases: The Third Manifesto" (http://www.acm.org/sigmod/record/issues/9503/manifesto.ps ). Которую написал никто иной, как Кристофер Дэйт.
Sapienti sat!
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 28.09.08 10:02
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>
Z>select ч.ФИО, д.Text from Человек ч left join Документ д on (д.ЧеловекИд=ч.Ид and д.ТипДокумента = ТипДокумента.Паспорт).
Z>

Z>Я так и не смог решить задачу с помощью HQL Есть идеи?
Есть:
select ч.ФИО, д.Text from Человек ч left join Документ д with (д.ЧеловекИд=ч.Ид and д.ТипДокумента = ТипДокумента.Паспорт)

Это если смотреть на грамматику HQL в Hibernate 3.2.
Sapienti sat!
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 28.09.08 10:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Есть:

C>
C>select ч.ФИО, д.Text from Человек ч left join Документ д with (д.ЧеловекИд=ч.Ид and д.ТипДокумента = ТипДокумента.Паспорт)
C>

C>Это если смотреть на грамматику HQL в Hibernate 3.2.

Только я говорил про NHibernate, он не понимает with по крайней мере когда я проверял последний раз.
... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 28.09.08 10:49
Оценка:
Здравствуйте, Ziaw, Вы писали:

C>>Это если смотреть на грамматику HQL в Hibernate 3.2.

Z>Только я говорил про NHibernate, он не понимает with по крайней мере когда я проверял последний раз.
Ну так нефиг пользоваться китайскими подделками

Можно тогда ещё вроде так переписать:
select ч.ФИО, д.Text from Человек ч left join Документ д on д.Человек=ч
whereis null) or (д.ТипДокумента = ТипДокумента.Паспорт)
Sapienti sat!
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 28.09.08 12:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>
C>select ч.ФИО, д.Text from Человек ч left join Документ д on д.Человек=ч
C>where
C>(д is null) or (д.ТипДокумента = ТипДокумента.Паспорт)
C>


on
коллекции Документы у человека нет. С джойнами не все так здорово в HQL. Можно перевернуть в Документ д right join д.Человек ч, но остается проблема джойнов в графе не являющимся деревом. Я писал уже на эту тему в этой ветке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 28.09.08 17:34
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Интегрированные в язык запросы — это nice to have. Основная заслуга Hibernate (произносится "Хайбернейт", кстати) — это способ представлять БД как набор объектов.

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

VD>http://ru.wikipedia.org/wiki/Hibernate_(библиотека)
VD>Основные возможности
VD>Явный упор на persistence, а не на mapping. Не правда ли?
Это проблемы конкретной статьи. Просто результатом нормального mapping'а графа объектов на реляционную базу данных будет являться удобный способ для persistance'а.

C>>Ну и представление ассоциаций в виде коллекций.

VD>Это и LINQ2SQL с успехом делает.
Это и SQL при желании умеет. Но я имел в виду другое.
Sapienti sat!
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 28.09.08 18:10
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>Нельзя.

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

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

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

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

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

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

Это уже скорее элементы ООБД. В Оракле так вообще ещё и объектные таблицы есть.

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

VD>Это, извините, батенька чушь несусветная. В классическом процедурном Паскале были записи. В классическом фунциональном ML-е записи и кортежи. Все эти типы структурированы и статически типизированы, но они не объекты и даже не классы! Это просто комплексные типы данных.
Если к записям в Паскале добавить полиморфизм — то это уже можно и считать объектами (см. "Оберон" ). Правда вырожденными, без поведения.

VD>Причем кортежи еще и имен не имеют. Кортежи вообще 1 в 1 повторяют описание строк таблиц БД (да и по сути родились из единой теории).

Ну вообще-то не 1-в-1. В реляционной алгебре есть операция RENAME.

C>>Да.

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

VD>А в чем разница то? Хоть убей не вижу из твоих рассуждений. Ведь если мы пользуемся только POD-типами (структурами и/иди кортежами), то разницы нет никакой. Ну, разве что умозрительная.

Ну да. Примерно так.

VD>А вот если мы начинаем по полной программе ООП впихивать (с его полиморфизмом и инкапсуляцией), то как раз и нарываемся на то, что ООП не содержит концепций позволяющих эффективно обрабатывать данные и принуждает к использованию неэффективного навигационного метода работы с данными.

Полиморфизм в RDB тоже можно выразить.

А вот навигационный принцип — это как раз то, что отличает OODB от RDB. В чистой RDB его нет (в реальных RDB он часто есть как оптимизация), в OODB он возможен как один из вариантов.
Sapienti sat!
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.09.08 02:50
Оценка:
Здравствуйте, ., Вы писали:
.>И правильно, остальное чисто инженерная нашлёпка для удобства использования, не несущая теоретического смысла.


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

S>>Оказывается, что большинству операторов РА в SQL нет прямых аналогов. А операторы, знакомые нам по SQL, в РА работают несколько по другому.
.>А подробнее? Что не так? Всё вроде есть, даже агрегатные ф-ции.
Здравствуйте, приехали.
1. В РА нет значения unknown для булевых предикатов
2. В РА проекция всегда требует distinct, что не применяется в SQL по причинам производительности
3. Операции над множествами в РА построены на именах атрибутов, в SQL — на их позициях
4. Что у нас является SQL-аналогом операции деления в РА?

.>Эээ... почему не является?

Потому, что в SQL нет, в отличие от РА, ограничения на уникальность строк.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.09.08 02:50
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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

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

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

C>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.09.08 03:07
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>А типизированный и структурированый элемент — это и есть объект.
Щас прям. Это ты где взял, неужто в хелпе про Хибернейт?
Типизированный и структурированный элемент — это record, он value-type в отличие от объекта, который обязан быть reference-типом. Потому, что иначе у него не будет идентичности.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 29.09.08 06:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Влад, уже несколько лет тут время от времени всплывает Gemstone/S.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[29]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 29.09.08 07:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>2) Объединения: натуральный джойн, тэта-джойн, outer left/right, inner join — всё тоже есть.

S>Да? И где в SQL натуральный джойн? Где семи-джойн? Где деление? Где антиджойн?
SELECT * FROM employee NATURAL JOIN department


Semi-join:
select *
from customer cust
where exists (
    select *
    from Sales sl
    where sl.cust_id = cust.cust_id)

Аналогично с делением и анти-джойном.

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

S>
S>Ее можно эмулировать на SQL без особых проблем. Тем не менее, SQL достаточно сильно отличается от "классической" РА, и именно потому, что "инженерные" соображения оказались важнее, чем 100% соответствие.
Он очень к ней близок.
Sapienti sat!
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 29.09.08 07:56
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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

S>Щас прям. Это ты где взял, неужто в хелпе про Хибернейт?
S>Типизированный и структурированный элемент — это record, он value-type в отличие от объекта, который обязан быть reference-типом. Потому, что иначе у него не будет идентичности.
Да, идентичность забыл. Но она тоже обеспечивается с помощью ORM, так что тут тоже не важно.
Sapienti sat!
Re[30]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.09.08 10:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

S>>Да? И где в SQL натуральный джойн? Где семи-джойн? Где деление? Где антиджойн?

C>
C>SELECT * FROM employee NATURAL JOIN department
C>

Да? Это из ANSI? Это хоть где-нибудь работает реально?

C>Semi-join:

C>
C>select *
C>from customer cust
C>where exists (
C>    select *
C>    from Sales sl
C>    where sl.cust_id = cust.cust_id)
C>

C>Аналогично с делением и анти-джойном.
Я же сказал — сконструировать на SQL реляционные операторы можно. Но это не означает, что "SQL построен на RA". Я вот могу деление и на XPath изобразить, и что, будем говорить что XPath построен на РА?

C>Он очень к ней близок.

... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 29.09.08 10:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>
C>>SELECT * FROM employee NATURAL JOIN department
C>>

S>Да? Это из ANSI? Это хоть где-нибудь работает реально?
В PostgreSQL работает:
http://www.postgresql.org/docs/8.0/interactive/queries-table-expressions.html
В MSSQL тоже, как и в Oracle.

S>Я же сказал — сконструировать на SQL реляционные операторы можно. Но это не означает, что "SQL построен на RA". Я вот могу деление и на XPath изобразить, и что, будем говорить что XPath построен на РА?

На XPath не изобразить остальные операции, AFAIK. Кстати, в самой РА достаточно только cross-join'а, всё остальное через него выражается (это если я не забываю что-то).
Sapienti sat!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 13:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Интегрированные в язык запросы — это nice to have. Основная заслуга Hibernate (произносится "Хайбернейт", кстати) —

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

C>это способ представлять БД как набор объектов.


Это-то и плохо. В прочем ты слишком вольно трактуешь цели Кибернейта. Меж тем они четко прописаны на сайте проекта.

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

VD>>http://ru.wikipedia.org/wiki/Hibernate_(библиотека)
VD>>Основные возможности
VD>>Явный упор на persistence, а не на mapping. Не правда ли?
C>Это проблемы конкретной статьи. Просто результатом нормального mapping'а графа объектов на реляционную базу данных будет являться удобный способ для persistance'а.

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

C>>>Ну и представление ассоциаций в виде коллекций.

VD>>Это и LINQ2SQL с успехом делает.
C>Это и SQL при желании умеет. Но я имел в виду другое.

SQL? В нем даже понятия "коллекции" нет. О чем ты?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 29.09.08 14:00
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>Интегрированные в язык запросы — это nice to have. Основная заслуга Hibernate (произносится "Хайбернейт", кстати) —

VD>Тогда уж "Гибирнейт". Но это уже детали.
Ну не нравится мне коверканье английских слов

C>>Это проблемы конкретной статьи. Просто результатом нормального mapping'а графа объектов на реляционную базу данных будет являться удобный способ для persistance'а.

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

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

C>>Это и SQL при желании умеет. Но я имел в виду другое.
VD>SQL? В нем даже понятия "коллекции" нет. О чем ты?
Я же сказал — "при желании".
Sapienti sat!
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 14:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

VD>>1. Названия.

C>У элементов кортежей в реляционной алгебре (см. операция RENAME) они тоже есть. Далее просто вводим название класса как alias для определённого набора названий кортежей.

Ладно. Это и правда мелочь.

VD>>2. Иерархия наследования.

C>Отображается на кортежи (дискриминатором, join-таблицами).

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

VD>>3. Полиморфизм.

C>Методы мы исключаем из рассмотрения.

Нет. Не исключаем. Или исключаем все и тогда остается только реляционная БД.

VD>>4. Инкапсуляция.

C>Аналогично, это требование элементарно удовлетворяется, если ORM имеет тот же доступ, что и члены самого класса.

Ну, и на фиг нам тогда вообще нужна какая-то там объектность, если мы все что было в ООП выкинули?
Получается эдакий хреновенький недо-линк. Такой, медленный, нетипизированный и с большим количеством гемороя вокруг него.

C>>>Так и получается.

VD>>Тогда это не ООБД, а БД со встроенным ОРМ. Думаю, не надо объяснять, что получить производительности чистой РСУБД при таком подходе не легче (читай невозможно) чем при подходе с отдельными ОРМ и СУБД?
C>Тут вопросы не в теории, а в практике. L2-кэш в ORMах сейчас повторяет внутренние кэши в БД, да ещё руками приходится следить за его когерентностью. Имело бы смысл его интегрировать в саму БД, например. Ну и так далее...

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

C>>>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.

VD>>Гы. Хранение в блобах — это не СУБД.
C>Нет, это СУБД, просто не реляционная.

ОК. Договорились! Такая СУБД была создана лет 50 назад. Называется — файл. Тебе ее должно хватить. Что тогда спорить о терминах? Мы же ведь просто под термином "СУБД" понимаем разные вещи.

VD>>А если используется реляционный движок, то это опять таки не ООБД, а надстройка.

VD>>Да и как иначе? Ведь много раз сказано было — ООП не был рассчитан на хранение данных в БД. Нет в нем соответствующих концепций. Концепции ООП отлично работают для классов в памяти, но никак для данных в БД. Более того ООП и средств обработки данных не предоставляет. Нельзя же считать императивные циклы таковыми?
C>Кем сказано было?

Мной.

C>Если хочешь почитать теоретически выкладки о том, что я говорю, то почитай "Foundation for Object Relational Databases: The Third Manifesto" (http://www.acm.org/sigmod/record/issues/9503/manifesto.ps ). Которую написал никто иной, как Кристофер Дэйт.


Ё! Опять постскипт? У меня складывается ощущение, что некоторые люди делают все, чтобы их не читали. Мне просто влом искать то чем это дело можно конвернуть в читабельный формат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 14:29
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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


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

Спорить с ним бесполезно, так как мы говорим, о том как Кибернэйм позиционируют его авторы, а он о том виртуальном Кибернейте который был создан его воображением путем ограничения возможностей и перенацеливания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 15:01
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Влад, уже несколько лет тут время от времени всплывает Gemstone/S.


Сам понимаешь. Тут всем мало дела до Смолтока. Потому и не замечают что там у вас всплывает.

В прочем это интересно. Есть внятное описание технической реализации этого чуда? А то по ссылкам я кроме маркетингового балшита так ничего и не нашел.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 15:20
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

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

C>Это уже скорее элементы ООБД. В Оракле так вообще ещё и объектные таблицы есть.

Ну, так чем тебе Оракл не ООБД?

C>Если к записям в Паскале добавить полиморфизм — то это уже можно и считать объектами (см. "Оберон" ). Правда вырожденными, без поведения.


И? Ты сам с собой поспорить хочешь?

VD>>Причем кортежи еще и имен не имеют. Кортежи вообще 1 в 1 повторяют описание строк таблиц БД (да и по сути родились из единой теории).

C>Ну вообще-то не 1-в-1. В реляционной алгебре есть операция RENAME.

А что в ФП есть проблемы с именованными записями или с ассоциацией имен с кортежами?
Еще раз повторю. Хотя бесполезно. Тебе хоть кол на голове теши, ты же не заметшь, что и описание, и само название "кортеж" говорит о общей базе.

C>>>Да.

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

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

VD>>А в чем разница то? Хоть убей не вижу из твоих рассуждений. Ведь если мы пользуемся только POD-типами (структурами и/иди кортежами), то разницы нет никакой. Ну, разве что умозрительная.

C>Ну да. Примерно так.

Ну, так ты просто используешь Кибернейт как эдакий нетипизированный Линк. Вот и все. При этом лезишь в спор на стороне тех, кто использует его как объектный персистер. Просто поспорить что-ли охота?

Забавно, что при этом ты в Линке какие-то проблемы находить умудрявшийся. Хотя казалось бы Линк — это Кибернейт созданный специально для твоей схемы работы с данными и при этом еще и статически типизированный.

Слушай, а не в том ли дело, что ты пишешь на Яве, где этого Кибера нет?

VD>>А вот если мы начинаем по полной программе ООП впихивать (с его полиморфизмом и инкапсуляцией), то как раз и нарываемся на то, что ООП не содержит концепций позволяющих эффективно обрабатывать данные и принуждает к использованию неэффективного навигационного метода работы с данными.

C>Полиморфизм в RDB тоже можно выразить.

Конечно можно. Но подходы другие. Они к ФП ближе.
Я вот как раз думал, что было бы прикольно сделать прозрачное отображение на БД такой штуки как Алгебраических Типов Данных (вариантов в терминах Немерла). На первый взгляд это не сложно реализовать и дало бы огромное преимущество во многих задачах. Прикинь? Паттерн-матчинг по БД?


C>А вот навигационный принцип — это как раз то, что отличает OODB от RDB. В чистой RDB его нет (в реальных RDB он часто есть как оптимизация), в OODB он возможен как один из вариантов.


Это где-то в РБД навигационных принцип? Дам даже понятия ссылок нет. Только соединение. Да и что в том хорошого? Не уж то так хочется этого гимора с кэшированием?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 29.09.08 15:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты такую ересь несешь, что просто в смех бросает. Это же надо такое придуать — "кортежи неструктурированных данных"?

VD>Просто ты под словом "неструктурированных" понимаешь только вложенных (как в объектах ООП). Меж тем кортежи и их списки позволяют структурировать данные намного гибче чем иерархии. И в иерархии их превратить не трудно. Тот же линк это делает легко. Тебе уже об этом раз сто сказали.
Вот и Hibernate это тоже делает, причём с меньшими затратами труда с моей стороны.

C>>Это уже скорее элементы ООБД. В Оракле так вообще ещё и объектные таблицы есть.

VD>Ну, так чем тебе Оракл не ООБД?
Интерфейс работает через SQL и в нём нет поддержки некоторым важным фичам.

VD>А что в ФП есть проблемы с именованными записями или с ассоциацией имен с кортежами?

VD>Еще раз повторю. Хотя бесполезно. Тебе хоть кол на голове теши, ты же не заметшь, что и описание, и само название "кортеж" говорит о общей базе.
Элементы кортежей в РБД — они атомарны. Т.е. у тебя будут кортеж ("Vasja", "Ivanov", 39) с заголовком (Name, LastName, Age). Hibernate позволяет из них прозрачно собрать структурирваный объект Person(Name, lastName, Age).

VD>Ну, так ты просто используешь Кибернейт как эдакий нетипизированный Линк. Вот и все. При этом лезишь в спор на стороне тех, кто использует его как объектный персистер. Просто поспорить что-ли охота?

Так ведь я использую Hibernate как объектный персистер, активно использую его поддержку идентичности объектов и lazy loading. Но это не мешает мне понимать, что под Hibernate'ом лежит обычная РБД.

VD>Забавно, что при этом ты в Линке какие-то проблемы находить умудрявшийся. Хотя казалось бы Линк — это Кибернейт созданный специально для твоей схемы работы с данными и при этом еще и статически типизированный.

VD>Слушай, а не в том ли дело, что ты пишешь на Яве, где этого Кибера нет?
Нет, я бы использовал Hibernate и в .NET.

VD>Я вот как раз думал, что было бы прикольно сделать прозрачное отображение на БД такой штуки как Алгебраических Типов Данных (вариантов в терминах Немерла). На первый взгляд это не сложно реализовать и дало бы огромное преимущество во многих задачах. Прикинь? Паттерн-матчинг по БД?

VD>
Поздно. В Хаскелле уже есть list comprehensions, работающие в БД.

VD>Это где-то в РБД навигационных принцип? Дам даже понятия ссылок нет. Только соединение. Да и что в том хорошого? Не уж то так хочется этого гимора с кэшированием?

Вот у тебя есть объект Студент, у него несколько объектов класса Оценка. Если известно, что обращение к оценкам ВСЕГДА идёт через объединение со студентом, то имеет смысл хранить оценки в одном блоке со студентом. В ООБД это совершенно естественно и называется "оптимизация путей доступа к данным", в РБД это делается как прозрачная оптимизация (есть в Oracle и MSSQL).
Sapienti sat!
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.08 16:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

Ладно. Я устал повторяться, по этому заканчиваю пререкаться с тобой. У тебя один фиг на все свое видение.

C>Вот и Hibernate это тоже делает, причём с меньшими затратами труда с моей стороны.


C>>>Это уже скорее элементы ООБД. В Оракле так вообще ещё и объектные таблицы есть.

VD>>Ну, так чем тебе Оракл не ООБД?
C>Интерфейс работает через SQL и в нём нет поддержки некоторым важным фичам.

Примеры приветствуются...

C>Элементы кортежей в РБД — они атомарны. Т.е. у тебя будут кортеж ("Vasja", "Ivanov", 39) с заголовком (Name, LastName, Age). Hibernate позволяет из них прозрачно собрать структурирваный объект Person(Name, lastName, Age).


А чем это отличается от названия таблицы БД и от примитивного мапинга предоставляемого Линк-ом?

C>Так ведь я использую Hibernate как объектный персистер, активно использую его поддержку идентичности объектов и lazy loading. Но это не мешает мне понимать, что под Hibernate'ом лежит обычная РБД.


Ты мне тут два дня доказывал, что Гибирнэйт — по-твоему — это такой более удобный Линк. А как до дело дошло, так вдруг заговорил об объектном персистере и ленивой загрузке которые тебе и приводили как пример неэффективной работы с данными. Ну, право, надо быть последовательнее.


VD>>Я вот как раз думал, что было бы прикольно сделать прозрачное отображение на БД такой штуки как Алгебраических Типов Данных (вариантов в терминах Немерла). На первый взгляд это не сложно реализовать и дало бы огромное преимущество во многих задачах. Прикинь? Паттерн-матчинг по БД?

VD>>
C>Поздно. В Хаскелле уже есть list comprehensions, работающие в БД.

Даже если забыть, что Хаскель как и Смолток — это эдакие программные проявления неуловимого Джо, то надо все же понимать, что list comprehensions — это всего лишь другой вид запросов. И при этом совершенно не обязательно чтобы при поддерживался паттерн-матчинг.

C>Вот у тебя есть объект Студент, у него несколько объектов класса Оценка. Если известно, что обращение к оценкам ВСЕГДА идёт через объединение со студентом, то имеет смысл хранить оценки в одном блоке со студентом. В ООБД это совершенно естественно и называется "оптимизация путей доступа к данным", в РБД это делается как прозрачная оптимизация (есть в Oracle и MSSQL).


А с чего бы это "обращение к оценкам ВСЕГДА идёт через объединение"? Скажем, решил я выявить сколько там у меня в институте пятерок за семестр поставили. Ну, и на фиг мне соединения делать какие-то со студентами?

Да и называй это как хочешь. Наличие объектов и иерархичности в Оракл — это не отменяет. Но у тебя явно какие-то двойные стандарты. Вот Каше, ядро которого об объектах слухом не слыхивало, у тебя ООБД, а Оркакл почему-то — нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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>Я же сказал — "при желании".

Я гляжу, ты что угодно "при желании" за уши притянешь. Ну, нельзя же так беседу строить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 29.09.08 16:31
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>Интерфейс работает через SQL и в нём нет поддержки некоторым важным фичам.

VD>Примеры приветствуются...
Идентичность объектов, например, не поддерживается.

C>>Элементы кортежей в РБД — они атомарны. Т.е. у тебя будут кортеж ("Vasja", "Ivanov", 39) с заголовком (Name, LastName, Age). Hibernate позволяет из них прозрачно собрать структурирваный объект Person(Name, lastName, Age).

VD>А чем это отличается от названия таблицы БД и от примитивного мапинга предоставляемого Линк-ом?
Тем что примитивный mapping делает автоматически Hibernate.

VD>Ты мне тут два дня доказывал, что Гибирнэйт — по-твоему — это такой более удобный Линк. А как до дело дошло, так вдруг заговорил об объектном персистере и ленивой загрузке которые тебе и приводили как пример неэффективной работы с данными. Ну, право, надо быть последовательнее.

Они НЕ неэффективные. Они просто очень своебразные, и в умелых руках очень быстрые.

C>>Поздно. В Хаскелле уже есть list comprehensions, работающие в БД.

VD>Даже если забыть, что Хаскель как и Смолток — это эдакие программные проявления неуловимого Джо, то надо все же понимать, что list comprehensions — это всего лишь другой вид запросов. И при этом совершенно не обязательно чтобы при поддерживался паттерн-матчинг.
Ну вряд ли что-то сильно иное получится.

VD>А с чего бы это "обращение к оценкам ВСЕГДА идёт через объединение"?

Ну приложение так устроено.

VD>Скажем, решил я выявить сколько там у меня в институте пятерок за семестр поставили. Ну, и на фиг мне соединения делать какие-то со студентами?

Тогда либо:
1) Смиряемся с тем, что этот запрос будет неэффективными и ждём лишние несколько секунд.
2) Откатываем оптимизацию и разбиваем данные на самостоятельные таблицы.

VD>Да и называй это как хочешь. Наличие объектов и иерархичности в Оракл — это не отменяет. Но у тебя явно какие-то двойные стандарты. Вот Каше, ядро которого об объектах слухом не слыхивало, у тебя ООБД, а Оркакл почему-то — нет.

Каше имеет объектный интерфейс, а ядро — это уже её личное дело. Мне вот тоже не очень интересно что там внутри DB4o делается.
Sapienti sat!
Re[32]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.09.08 10:27
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В PostgreSQL работает:

C>http://www.postgresql.org/docs/8.0/interactive/queries-table-expressions.html
C>В MSSQL тоже, как и в Oracle.
В MS SQL этого никогда не было. http://msdn.microsoft.com/en-us/library/ms177634.aspx.

C>На XPath не изобразить остальные операции, AFAIK.

Изобразить-изобразить.
C>Кстати, в самой РА достаточно только cross-join'а, всё остальное через него выражается (это если я не забываю что-то).
Достаточно четырех т.н. основных операторов. Без rename одними джойнами не всё получится обойтись.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: Константин Л. Франция  
Дата: 30.09.08 16:12
Оценка:
Здравствуйте, Aikin, Вы писали:

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


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

A>>>1) Вы не ответили на вопрос. Как избыточность/неизбыточность соотносится с "методы класс должны заниматься только тем, что требует доступа к его приватным данным"?
C>>Тем и относится. Добавление в коллекцию не требует доступа к приватным данным, следовательно этих методов быть не должно.
A>Сама коллекция -- приватные данные. То что ее выкинули наружу -- ошибка проектирования. По-хорошему там достаточно IEnumerable и доступа по индексу, в крайнем случае коллецию нужно сделать ReadOnly. Но не выставлять ее публично всем на растерзание.

тут понимаешь в чем дело, мы вынуждены идти на компромисс. Если коллекция чего либо ест его неотъемлемое свойство и доступ к ней нужно обеспечить широкий (CRUD ), то может быть имеет смысл ее выставить всю как есть, чем дублировать ее интерфейс в паренте. Если же операция пара тройка, то я бы предпочел ее закрыть как можно плотнее. Вообще, люблю private )

[]
Re: По итогам дискусии напрашивается вопрос
От: Константин Л. Франция  
Дата: 30.09.08 21:00
Оценка:
Здравствуйте, Аноним, Вы писали:

[]

какие выводы я сделал для себя (далее под linq будет пониматься linq2sql):

1. orm почти всегда плохо
2. 3-tier хорошо, тк не нагружаем сиквел etc.
3. linq рулит

Вопросов 2:

1. куда приткнуть линк в трехзвенке _эффективно_? Выставляем вэбсервисы, внутри которых юзаем линк, а на клиенте имеем все те же рукописные BO, которые ws выплевывают? Или есть средства для передачи результирующего sql кода на app server и далее app server сам разбирается с сиквелом?
2. чем делать insert/delete/update кроме как не sp?

спасибо
Re[33]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 30.09.08 22:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>В MSSQL тоже, как и в Oracle.

S>В MS SQL этого никогда не было. http://msdn.microsoft.com/en-us/library/ms177634.aspx.
Я его там где-то видел...

Кстати, в ANSI SQL-92 он есть

Significant new features are:

5) Additional set operators (for example, union join, natural join,
set difference, and set intersection),
...

<qualified join> ::=
<table reference> [ NATURAL ] [ <join type> ] JOIN
<table reference> [ <join specification> ]

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

C>>Кстати, в самой РА достаточно только cross-join'а, всё остальное через него выражается (это если я не забываю что-то).

S>Достаточно четырех т.н. основных операторов. Без rename одними джойнами не всё получится обойтись.
Я имею в виду, что все джойны выражаются через cross-join.
Sapienti sat!
Re[2]: По итогам дискусии напрашивается вопрос
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 01.10.08 06:25
Оценка:
Здравствуйте, Константин Л., Вы писали:

A>>Сама коллекция -- приватные данные. То что ее выкинули наружу -- ошибка проектирования. По-хорошему там достаточно IEnumerable и доступа по индексу, в крайнем случае коллецию нужно сделать ReadOnly. Но не выставлять ее публично всем на растерзание.

КЛ>тут понимаешь в чем дело, мы вынуждены идти на компромисс. Если коллекция чего либо ест его неотъемлемое свойство и доступ к ней нужно обеспечить широкий (CRUD ), то может быть имеет смысл ее выставить всю как есть, чем дублировать ее интерфейс в паренте. Если же операция пара тройка, то я бы предпочел ее закрыть как можно плотнее. Вообще, люблю private )
Ну про компромисы я знаю. И про отличия теории и практики.

СУВ, Aikin
Re[9]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 01.10.08 07:29
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Кстати, нашел у г-на Шварца вот такое, как MapReduce for the Petabyte Database:

Greenplum gives enterprises the best of both worlds – MapReduce for programmers and SQL for DBAs – and will execute both MapReduce and SQL directly within Greenplum’s parallel dataflow engine, which is at the heart of the Greenplum Database.

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: По итогам дискусии напрашивается вопрос
От: Константин Л. Франция  
Дата: 01.10.08 07:59
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Константин Л., Вы писали:


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

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

S>а) Lazy Load

S>б) Navigational Access
S>в) Overcaching

Я говорю про full-blown.

[]

КЛ>>3. linq рулит


[]

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


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


S>Не очень понятно, откуда BO на клиенте в трёхзвенке. В трёхзвенке клиент достаточно тонкий, он видит только DTO, ему крайне противопоказано гонять свою логику. Логика отображения, плюс заемная (например, частичная валидация вводимых данных) — вот его удел.

КЛ>>Или есть средства для передачи результирующего sql кода на app server и далее app server сам разбирается с сиквелом?
S>Не очень понятно, что такое "результирующий SQL код"? SQL код формируется внутри апп.сервера и отдается сиквелу на исполнение. Клиент полностью изолирован от SQL кода в каком бы то ни было виде.

Ok, пусть будет DTO. SQL код генерируется где угодно, а в нашем случае он генерится линком. Соответственно, ты пишешь о том, о чем я тебя спрашиваю:

Сейчас народ постепенно копает идею готовить линк-запросы на клиенте и передавать их апп.серверу.


Ведь можно гонять sql, а можно сами линк-запросы, как здесь
Автор: Igor Sukhov
Дата: 29.09.08
. И пока получается, что на клиенте линк не приткнешь

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


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


[]

Именно на клиенте linq2sql меня и интересует, иначе все так же возиться с ws

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

S>Как чем? Простой SQL вполне себе подойдет. Вот статья со всеми подробностями.

Пробежался. Что там с транзакциями?
Re[4]: По итогам дискусии напрашивается вопрос
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.08 08:14
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Я говорю про full-blown.

Ок. Linq != FBORM.
КЛ>[]


КЛ>Ok, пусть будет DTO. SQL код генерируется где угодно, а в нашем случае он генерится линком. Соответственно, ты пишешь о том, о чем я тебя спрашиваю:


КЛ>

КЛ>Сейчас народ постепенно копает идею готовить линк-запросы на клиенте и передавать их апп.серверу.


КЛ>Ведь можно гонять sql, а можно сами линк-запросы, как здесь
Автор: Igor Sukhov
Дата: 29.09.08
.

Именно про этот народ я и имел в виду

КЛ>И пока получается, что на клиенте линк не приткнешь

Ну.. Меня, к примеру, вполне устраивает в качестве клиента браузер. Отсутствие в нем линка лично мне пока что никакой боли не приносит

КЛ>Именно на клиенте linq2sql меня и интересует, иначе все так же возиться с ws

Концепция Linq2Remote пока не проработана никак. Полтора года тому я спрашивал Хейльсберга на эту тему, и он ответил что-то типа "мы не против, если вы будете сериализовывать Linq запросы для удаленного исполнения, но пока что мы не можем придумать достаточно обобщенную реализацию для включения в FCL. Есть несколько фундаментальных вопросов, которые легко решить для конкретного проекта, но общего ответа на них не существует".

КЛ>Пробежался. Что там с транзакциями?

Вроде всё в порядке Делаешь SubmitChanges(), и они делаются в одной транзакции.

Transactions
A transaction is a service provided by a database (or other resource manager) to guarantee that a series of individual actions occur atomically — meaning either they all succeed or they all don't, and if they don't then they are all automatically undone before anything else is allowed to happen.

When you call SubmitChanges() on your DataContext, the updates will always be wrapped in a Transaction. This means that your database will never be in an inconsistent state if you perform multiple changes — either all of the changes you've made on your DataContext are saved, or none of them are.

If no transaction is already in scope, the LINQ to SQL DataContext object will automatically start a database transaction to guard updates when you call SubmitChanges(). Alternatively, LINQ to SQL also enables you to explicitly define and use your own TransactionScope object (a feature introduced in .NET 2.0). This makes it easier to integrate LINQ to SQL code with existing data access code you already have. It also means that you can enlist non-database resources into the transaction — for example: you could send off a MSMQ message, update the file-system (using the new transactional file-system support), etc — and scope all of these work items in the same transaction that you use to update your database with LINQ to SQL.

http://weblogs.asp.net/scottgu/archive/2007/07/11/linq-to-sql-part-4-updating-our-database.aspx
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: По итогам дискусии напрашивается вопрос
От: Константин Л. Франция  
Дата: 01.10.08 08:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Константин Л., Вы писали:


КЛ>>Я говорю про full-blown.

S>Ок. Linq != FBORM.

это ясно

КЛ>>[]



КЛ>>Ok, пусть будет DTO. SQL код генерируется где угодно, а в нашем случае он генерится линком. Соответственно, ты пишешь о том, о чем я тебя спрашиваю:


КЛ>>

КЛ>>Сейчас народ постепенно копает идею готовить линк-запросы на клиенте и передавать их апп.серверу.


КЛ>>Ведь можно гонять sql, а можно сами линк-запросы, как здесь
Автор: Igor Sukhov
Дата: 29.09.08
.

S>Именно про этот народ я и имел в виду

КЛ>>И пока получается, что на клиенте линк не приткнешь

S>Ну.. Меня, к примеру, вполне устраивает в качестве клиента браузер. Отсутствие в нем линка лично мне пока что никакой боли не приносит

Ну под клиентом я понимаю presentation в виде asp.net ect. Потенциально, linq2remote помог бы с, одной стороны, избавиться от ws, я с другой сохранить 3-tier

[]
Re[10]: Взаимодействие с Базой Данных из C# по схеме MS
От: Sinix  
Дата: 01.10.08 08:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Эммм... насколько помню, MapReduce собсно — разработка гугля с заимствованием идей из ФП и предназначена для эффективной параллельной обработки терабайт однородных данных. Не самый распространённый вариант, а?

ИМХО, не тянет на конкурента СУБД. На низкоуровневое distributed storage — ещё да.

Далее. Не мне вам объяснять, что совершенство технологии и её распространённость — слегка разные вещи, а уж обосновывать перспективность чего-либо, основываясь на то, что "факторы указывают" — пошловато как-то получается. Прям как мракетолог какой-то или брокер, прости господи Вот когда оно дорастёт до уровня мэйнстрима, дабы можно было это пощупать — тогда и будем обсуждать.
Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 01.10.08 08:59
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Далее. Не мне вам объяснять,


Вообщето ты отвечаеш не на мой пост, а на предыдущий

S> Вот когда оно дорастёт до уровня мэйнстрима, дабы можно было это пощупать — тогда и будем обсуждать.


По ссылке которую я дал, там самый что ни на есть майнстрим.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: По итогам дискусии напрашивается вопрос
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.08 09:10
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Ну под клиентом я понимаю presentation в виде asp.net ect. Потенциально, linq2remote помог бы с, одной стороны, избавиться от ws, я с другой сохранить 3-tier

Лично я в Asp.Net понимаю под клиентом именно клиента, т.е. браузер. Там нет никаких BO и Linq, а DTO ездят в виде JSON или XML.
Так что linq получается офигенно удобным там, где он есть, безо всяких ws.

А то, о чем ты говоришь, это уже фактически не 3-tier, а SOA: разделение среднего слоя на набор слабо связанных сервисов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: По итогам дискусии напрашивается вопрос
От: Константин Л. Франция  
Дата: 01.10.08 10:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Константин Л., Вы писали:


КЛ>>Ну под клиентом я понимаю presentation в виде asp.net ect. Потенциально, linq2remote помог бы с, одной стороны, избавиться от ws, я с другой сохранить 3-tier

S>Лично я в Asp.Net понимаю под клиентом именно клиента, т.е. браузер. Там нет никаких BO и Linq, а DTO ездят в виде JSON или XML.

ок, т.е. голый ajax без каких либо тяжелых server-side asp.net страниц?

S>Так что linq получается офигенно удобным там, где он есть, безо всяких ws.


S>А то, о чем ты говоришь, это уже фактически не 3-tier, а SOA: разделение среднего слоя на набор слабо связанных сервисов.


ну они не слабо связанные, тем более что asp.net pages и ws и есть то самое разделение
Re[8]: По итогам дискусии напрашивается вопрос
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.08 10:23
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>ок, т.е. голый ajax без каких либо тяжелых server-side asp.net страниц?

Ну, я не знаю, что значит "тяжелых"
Можно делать и тяжелые страницы — один хрен, это всего лишь повлияет на производительность. Ну будут туда приезжать DTO в виде сразу размеченного HTML.
S>>Так что linq получается офигенно удобным там, где он есть, безо всяких ws.
КЛ>ну они не слабо связанные, тем более что asp.net pages и ws и есть то самое разделение
Разделение на что? ASP.NET не нуждается в WS. WS нужны исключительно для кроссплатформенного взаимодействия; тебе никто не запрещает сделать не tier, а layer — то есть разделить средний слой (ASP.NET сервер) на presentation layer и application layer, обращаясь из первого ко второму при помощи Linq. Физически всё при этом будет ездить в рамках одного процесса (домена).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: По итогам дискусии напрашивается вопрос
От: Константин Л. Франция  
Дата: 01.10.08 10:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

[]

S>>>Так что linq получается офигенно удобным там, где он есть, безо всяких ws.

КЛ>>ну они не слабо связанные, тем более что asp.net pages и ws и есть то самое разделение
S>Разделение на что? ASP.NET не нуждается в WS. WS нужны исключительно для кроссплатформенного взаимодействия; тебе никто не запрещает сделать не tier, а layer — то есть разделить средний слой (ASP.NET сервер) на presentation layer и application layer, обращаясь из первого ко второму при помощи Linq. Физически всё при этом будет ездить в рамках одного процесса (домена).

ок, интересует архитектура вида pres. layer (asp.net) -> app layer (?) -> sql serv. Причем обмен м/у pres., app, sql через linq (все они физически разнесены). Похоже, что готового решения нет, да и нужно ли оно?
Re[10]: По итогам дискусии напрашивается вопрос
От: Sinclair Россия https://github.com/evilguest/
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Взаимодействие с Базой Данных из C# по схеме MS
От: . Великобритания  
Дата: 01.10.08 13:57
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>На XPath не изобразить остальные операции, AFAIK.

S>Изобразить-изобразить.
Как например изобразить хотя бы cross join? (или ты xpath 2.0 имеешь в виду?)
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: По итогам дискусии напрашивается вопрос
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.10.08 14:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Константин Л., Вы писали:


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

S>Совершенно верно — нет.
Неправда, есть. ADO.NET Data Services зовется.

КЛ>>да и нужно ли оно?

S>Нужно, хоть и редко. На самом деле, я уверен, что как только появится удачная реализация, ее востребованность резко возрастет. А через пару лет вообще будет считаться, что без этого жить незачем
Реализация есть, посмотри как будет чуствовать себя к выходу четвертого фреймворка.
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: Ziaw Россия  
Дата: 01.10.08 18:23
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


Что интересно, то же самое можно сказать про тебя и линк Ты игноригруешь ORM часть linq2sql и концентрируешься на запросах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>
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[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[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 07.11.08 15:22
Оценка:
Здравствуйте, Sergey T., Вы писали:

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


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

В этом и есть главная проблема ORM. Предлагаемые решения позволяют себя криво использовать и часто даже подталкивают к этому.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 07.11.08 15:28
Оценка:
Здравствуйте, IT, Вы писали:

IT>Архитектура может быть идеальной, но позволять криво себя использовать. Если кривое использование такой архитектуры происходит с завидной регулярностью, то это становится проблемой самой архитекруры и такую архитектуру можно смело называть кривой.

Ага. Нужно оставить только лом — его только по назначению можно использовать.

IT>В этом и есть главная проблема ORM. Предлагаемые решения позволяют себя криво использовать и часто даже подталкивают к этому.

Что самое прикольное, то даже MS поняла, что ORM делает LINQ2SQL и прочие низкоуровневые технологии не особо нужным. Всё в точности, как я и говорил когда-то.
Sapienti sat!
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 07.11.08 15:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>Архитектура может быть идеальной, но позволять криво себя использовать. Если кривое использование такой архитектуры происходит с завидной регулярностью, то это становится проблемой самой архитекруры и такую архитектуру можно смело называть кривой.

C>Ага. Нужно оставить только лом — его только по назначению можно использовать.

С ломом это к Дворкину. Решение должно быть защищено от неправильного использования. Или ты с этим не согласен.

IT>>В этом и есть главная проблема ORM. Предлагаемые решения позволяют себя криво использовать и часто даже подталкивают к этому.

C>Что самое прикольное, то даже MS поняла, что ORM делает LINQ2SQL и прочие низкоуровневые технологии не особо нужным. Всё в точности, как я и говорил когда-то.

Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 07.11.08 17:12
Оценка:
Здравствуйте, IT, Вы писали:

C>>Ага. Нужно оставить только лом — его только по назначению можно использовать.

IT>С ломом это к Дворкину. Решение должно быть защищено от неправильного использования. Или ты с этим не согласен.
Но не до такой степени, что при этом становится бесполезным.

IT>Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо.

Ну вот как перепоймут — так я и окажусь неправ
Sapienti sat!
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 07.11.08 17:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>С ломом это к Дворкину. Решение должно быть защищено от неправильного использования. Или ты с этим не согласен.

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

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

IT>>Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо.

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

Да ты уже неправ, защищая решения, в которые их проблемность заложена в саму архитектуру.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 07.11.08 23:34
Оценка: +1
Здравствуйте, IT, Вы писали:

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

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

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

IT>Да ты уже неправ, защищая решения, в которые их проблемность заложена в саму архитектуру.
Так это вообще ВСЕ решения.
Sapienti sat!
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 08.11.08 01:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Ну сосчитал, и что?

То, что проблемы Хайбернейта легко сосчитать, и эта величина далеко не стремится к нулю.

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

IT>>Да ты уже неправ, защищая решения, в которые их проблемность заложена в саму архитектуру.
C>Так это вообще ВСЕ решения.

Это правда. Любое решение обладает как положительными, так и отрицательными качествами. Но как я уже говорил, если архитектура позволяет криво себя использовать или даже провоцирует к этому, то от такого решения будет больше проблем, чем пользы.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 08.11.08 01:59
Оценка:
Здравствуйте, IT, Вы писали:

C>>Ну сосчитал, и что?

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

C>>Так это вообще ВСЕ решения.

IT>Это правда. Любое решение обладает как положительными, так и отрицательными качествами. Но как я уже говорил, если архитектура позволяет криво себя использовать или даже провоцирует к этому, то от такого решения будет больше проблем, чем пользы.
Тот же .NET можно использовать ТАК криво, что он просто будет под углом 90 градусов стоять. И что дальше? Перевес от использования managed-языка и нормальной библиотеки превышает потери от кривоты. Вот та же ситуация с Hibernate и ORM вообще.
Sapienti sat!
Re[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 08.11.08 06:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Ну сосчитал, и что?

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

BLToolkit тоже даёт мне нехилый плюс, но при этом без побочных эффектов. Побочные эффекты нужно выявлять и устранять. Ты же пытаешься их оправдать. И это не правильно. Скажи просто — Hibernate классная либа, но некоторые решения в ней на редкость уродские, и на этом наша дискуссия прекратится

IT>>Это правда. Любое решение обладает как положительными, так и отрицательными качествами. Но как я уже говорил, если архитектура позволяет криво себя использовать или даже провоцирует к этому, то от такого решения будет больше проблем, чем пользы.

C>Тот же .NET можно использовать ТАК криво, что он просто будет под углом 90 градусов стоять.

Например? Только не надо копировать откровенно кривые решения с http://thedailywtf.com/.

C>И что дальше? Перевес от использования managed-языка и нормальной библиотеки превышает потери от кривоты. Вот та же ситуация с Hibernate и ORM вообще.


Зачем упорствовать? Недавно тут был целый тред, где тебе популярно разъяснили все проблемы ORM. Не стоит уподобляться всяким лойдам, которые с достойной только дебилам упорством задают одни и те же вопросы, на ответы на эти же вопросы.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 08.11.08 14:47
Оценка:
Здравствуйте, IT, Вы писали:

IT>BLToolkit тоже даёт мне нехилый плюс, но при этом без побочных эффектов. Побочные эффекты нужно выявлять и устранять. Ты же пытаешься их оправдать. И это не правильно. Скажи просто — Hibernate классная либа, но некоторые решения в ней на редкость уродские, и на этом наша дискуссия прекратится

Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует.

C>>Тот же .NET можно использовать ТАК криво, что он просто будет под углом 90 градусов стоять.

IT>Например? Только не надо копировать откровенно кривые решения с http://thedailywtf.com/.
Например, наделать memory leak'ов, считая что их не может быть в принципе.

C>>И что дальше? Перевес от использования managed-языка и нормальной библиотеки превышает потери от кривоты. Вот та же ситуация с Hibernate и ORM вообще.

IT>Зачем упорствовать? Недавно тут был целый тред, где тебе популярно разъяснили все проблемы ORM. Не стоит уподобляться всяким лойдам, которые с достойной только дебилам упорством задают одни и те же вопросы, на ответы на эти же вопросы.
Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда.

До MS тоже это дошло, и они придумали EF.
Sapienti sat!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 08.11.08 18:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует.


Лидирует в чём?

C>Например, наделать memory leak'ов, считая что их не может быть в принципе.


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

C>Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда.


Я не сомневаюсь в правильности твоего вывода. Но это не делает эту технологию менее проблемной.

C>До MS тоже это дошло, и они придумали EF.


Я тебе уже говорил, MS много чего придумывает. Но не всё что придумывает MS гениально и становится востребованным. Могу привести ешё один пример — WWF, зачётная технология, но на практике для небольших проектов высоковат уровень вхождения, для больших высоковат уровень поддержки.

Что будет с EF посмотрим. Мой прогноз — мыши плакали, кололись, но продолжали жрать кактус
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 08.11.08 22:21
Оценка:
Здравствуйте, IT, Вы писали:

C>>Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует.

IT>Лидирует в чём?
В скорости разработки и цене поддержки.

C>>Например, наделать memory leak'ов, считая что их не может быть в принципе.

IT>Ликов не может быть в принципе. Но можно зацепить объекты за статические переменные или за события и тогда они не будут освобождены никогда.
Это обычно и называют "memory leak"'ами в managed-приложения.

IT>Но это не лики, это проблема дизайна.

Это я и имею в виду.

C>>Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда.

IT>Я не сомневаюсь в правильности твоего вывода. Но это не делает эту технологию менее проблемной.
Если технология проблемная, но работает, то она не проблемная

IT>Я тебе уже говорил, MS много чего придумывает. Но не всё что придумывает MS гениально и становится востребованным. Могу привести ешё один пример — WWF, зачётная технология, но на практике для небольших проектов высоковат уровень вхождения, для больших высоковат уровень поддержки.

WWF просто сам по себе достаточно нишевая технология.

IT>Что будет с EF посмотрим. Мой прогноз — мыши плакали, кололись, но продолжали жрать кактус

Мой прогноз: мы увидим дальнейшее движение в сторону от баз данных и голого SQL к более высокоуровневым средствам. EF будут совершенствовать, возможно интегрировав в SQL Server частичную поддержку для средств ООП.
Sapienti sat!
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.11.08 22:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Мой прогноз: мы увидим дальнейшее движение в сторону от баз данных и голого SQL к более высокоуровневым средствам. EF будут совершенствовать, возможно интегрировав в SQL Server частичную поддержку для средств ООП.


Зная примерно, что ис себя представляет тим, который EF занимается, я бы тебе не советовал особо на это рассчитывать.
Кстати, какое то время это чудо пытались как раз mssql team спихнуть, но те от него отпихались руками и ногами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 08.11.08 22:50
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

AVK>Кстати, какое то время это чудо пытались как раз mssql team спихнуть, но те от него отпихались руками и ногами.
Вполне представляю. Чтоб написать нормальный ORM нужно набить достаточно много шишек. Сам .NET тоже в первом релизе был печальным зрелищем.
Sapienti sat!
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.11.08 23:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вполне представляю. Чтоб написать нормальный ORM нужно набить достаточно много шишек.


Шишки там начинались еще с ObjectSpaces, если не раньше. Не обольщайся, это не временные шишки, это уже устоявшиеся воззрения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 08.11.08 23:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>>Вполне представляю. Чтоб написать нормальный ORM нужно набить достаточно много шишек.

AVK>Шишки там начинались еще с ObjectSpaces, если не раньше. Не обольщайся, это не временные шишки, это уже устоявшиеся воззрения.
ObjectSpaces — это был очень примитивный фреймворк. Интересно, а его команда в развитии EF участвовала?

Вообще, хороший ORM-фреймворк — это весьма сложная штука. Слишком многое можно сделать неправильно.
Sapienti sat!
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[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 08.11.08 23:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

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


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

AVK>Да. Выдающаяся по количеству убитых проектов команда (WinFS тоже на их груди сияет, если что).
Охх... Да. Теперь я понял всю глубину ситуации.

AVK>Я вот уже думал, что наконец то один успешный проект появился — linq2sql. Ан нет, они и его похоронили. И EF они тоже похоронят, не сомневайся Неудачники

Осталось перевести эту группу в отдел ядра Windows, и Линукс можно считать победившим.

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

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

Впрочем, Microsoft любит на покупателях эксперименты ставить.
Sapienti sat!
Re[29]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.11.08 00:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Осталось перевести эту группу в отдел ядра Windows, и Линукс можно считать победившим.


Там своих индусов хватает. Но там башка имеется из суровых мужиков, в отличие от.

C>Впрочем, Microsoft любит на покупателях эксперименты ставить.


Ну, это ты зря. МС как раз таки очень не любит рискованных стратегий, за что ее регулярно полоскают в том числе и на этом форуме. Мол, вот, опять, ну ничего революционного, все стырили.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[30]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 09.11.08 01:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>>Осталось перевести эту группу в отдел ядра Windows, и Линукс можно считать победившим.

AVK>Там своих индусов хватает. Но там башка имеется из суровых мужиков, в отличие от.
Пусть возьмут на работу создателя Hibernate — он может им расскажет как не надо делать

C>>Впрочем, Microsoft любит на покупателях эксперименты ставить.

AVK>Ну, это ты зря. МС как раз таки очень не любит рискованных стратегий, за что ее регулярно полоскают в том числе и на этом форуме. Мол, вот, опять, ну ничего революционного, все стырили.
Ну некоторые продукты МС никак кроме как бэта-версиями назвать нельзя. Тут Vista лидирует, которая до SP1 имела кучу критичных проблем.
Sapienti sat!
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.11.08 01:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну некоторые продукты МС никак кроме как бэта-версиями назвать нельзя. Тут Vista лидирует, которая до SP1 имела кучу критичных проблем.


Ну, лично я ничего критичного не заметил. Опять же, смотря с чем сравнивать. По сравнению с очередным продуктом адоба или автодеска виста просто идеал безглючности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[32]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 09.11.08 01:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>>Ну некоторые продукты МС никак кроме как бэта-версиями назвать нельзя. Тут Vista лидирует, которая до SP1 имела кучу критичных проблем.

AVK>Ну, лично я ничего критичного не заметил. Опять же, смотря с чем сравнивать.
Баги с копированием файлов не иначе как бэта-тестом на пользователях назвать нельзя было, например.

AVK>По сравнению с очередным продуктом адоба или автодеска виста просто идеал безглючности.

Ну да, это они пример у MS взяли.
Sapienti sat!
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: yuriylsh  
Дата: 09.11.08 02:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо.

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

Боюсь, касаемо L2S — уже Здесь и далее по ссылкам
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 09.11.08 02:13
Оценка:
Здравствуйте, yuriylsh, Вы писали:

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

Y>Боюсь, касаемо L2S — уже Здесь и далее по ссылкам
Собственно, я именно об этом и говорю.
Sapienti sat!
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 09.11.08 07:23
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует.

IT>>Лидирует в чём?
C>В скорости разработки и цене поддержки.

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

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

C>Это обычно и называют "memory leak"'ами в managed-приложения.

Так это называют только невежды.

C>>>Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда.

IT>>Я не сомневаюсь в правильности твоего вывода. Но это не делает эту технологию менее проблемной.
C>Если технология проблемная, но работает, то она не проблемная

Проблемная технология всегда остаётся проблемной. Умение ходить по граблям не уменьшает количество граблей. C++ девелоперы всю жизнь ходят по граблям и это не делает C++ более качественной технологией. Точно так же и с Хайбернейт.

IT>>Что будет с EF посмотрим. Мой прогноз — мыши плакали, кололись, но продолжали жрать кактус

C>Мой прогноз: мы увидим дальнейшее движение в сторону от баз данных и голого SQL к более высокоуровневым средствам. EF будут совершенствовать, возможно интегрировав в SQL Server частичную поддержку для средств ООП.

Вот тоже хороший пример. Когда в SQL 2005 добавляли поддержку .NET, то крику было немеряно. В результате оказалось чисто маркетинговый ход, в Oracle Java, в MS SQL .NET. Добавили и успокоились, а на практике практически никто не использует.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 09.11.08 11:54
Оценка:
Здравствуйте, IT, Вы писали:

C>>В скорости разработки и цене поддержки.

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

C>>Это обычно и называют "memory leak"'ами в managed-приложения.

IT>Так это называют только невежды.
Нет. Это устоявшаяся терминилогия:
http://www.ej-technologies.com/products/jprofiler/overview.html
http://radio.weblogs.com/0118231/stories/2005/07/21/tipsForUsingHeapWindowAndMemoryProfilerToFindMemoryLeaks.html
...

IT>Вот тоже хороший пример. Когда в SQL 2005 добавляли поддержку .NET, то крику было немеряно. В результате оказалось чисто маркетинговый ход, в Oracle Java, в MS SQL .NET. Добавили и успокоились, а на практике практически никто не использует.

Это было вполне предсказуемо. Нужна не возможность запуска хранимых процедур на .NET, а именно интеграция с самой системой хранения и представления данных.
Sapienti sat!
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 09.11.08 17:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>О как? Интересно, какими ты методиками пользовался при оценке скорости разработки и цены поддержки?

C>По времени разработки новых фич и проценту времени на багфиксинг.

И как долго ты использовал BLToolkit, чтобы научиться его эффективно использовать? А Хайбернейт.

IT>>Так это называют только невежды.

C>Нет. Это устоявшаяся терминилогия:
C>http://www.ej-technologies.com/products/jprofiler/overview.html
C>http://radio.weblogs.com/0118231/stories/2005/07/21/tipsForUsingHeapWindowAndMemoryProfilerToFindMemoryLeaks.html
C>...

Так это Java, может в ней и есть лики, я не в курсе.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 10.11.08 11:32
Оценка:
Здравствуйте, IT, Вы писали:

C>>По времени разработки новых фич и проценту времени на багфиксинг.

IT>И как долго ты использовал BLToolkit, чтобы научиться его эффективно использовать? А Хайбернейт.
Команда, которая его использовала, имела опыт примерно в год его использования. Hibernate я использовал дольше, но команда выучилась сравнительно быстро.

C>>http://radio.weblogs.com/0118231/stories/2005/07/21/tipsForUsingHeapWindowAndMemoryProfilerToFindMemoryLeaks.html

IT>Так это Java, может в ней и есть лики, я не в курсе.
Имеются в виду те же самые лики — если граф объектов зацепляется за какую-то статическую переменную.

Вот для .NET:
http://www.automatedqa.com/techpapers/net_allocation_profiler.asp
http://memprofiler.com/?gclid=CJSnr-jB6pYCFQ9WtAoduUcrPQ
Sapienti sat!
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: IT Россия linq2db.com
Дата: 10.11.08 14:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>И как долго ты использовал BLToolkit, чтобы научиться его эффективно использовать? А Хайбернейт.

C>Команда, которая его использовала, имела опыт примерно в год его использования. Hibernate я использовал дольше, но команда выучилась сравнительно быстро.

Понятно. Сам ты не знаешь. Жаль. Хотелось бы пообщаться с теми, кто всё-таки пробовал вкус апельсина.

C>Имеются в виду те же самые лики — если граф объектов зацепляется за какую-то статическую переменную.

C>Вот для .NET:

Я ещё раз повторяю, это безграмотно. Использование этого термина для обозначения совершенно другой проблемы обосновано внешней похожестью проблемы и бедной фантазией людей его использующего.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 13.11.08 20:21
Оценка:
Здравствуйте, IT, Вы писали:

C>>Команда, которая его использовала, имела опыт примерно в год его использования. Hibernate я использовал дольше, но команда выучилась сравнительно быстро.

IT>Понятно. Сам ты не знаешь. Жаль. Хотелось бы пообщаться с теми, кто всё-таки пробовал вкус апельсина.
Знаю, почему же. По-моему, по твоей рекомендации его в первый раз и посмотрел.

C>>Вот для .NET:

IT>Я ещё раз повторяю, это безграмотно. Использование этого термина для обозначения совершенно другой проблемы обосновано внешней похожестью проблемы и бедной фантазией людей его использующего.
Придумай другой термин Я где-то видел "excessive object retention", но как-то совсем не звучит.
Sapienti sat!
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 20.11.08 15:46
Оценка:
Здравствуйте, Sergey T., Вы писали:

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

Именно... Фишка-то ровно в том, что если присмотреться к типичному приложению, которое активно использует БД, то там процентов 90-95 работы — это отчеты. Список товаров в заказе — отчет, история заказов — отчет, адреса доставки — отчет, ect...

ST>Однако, ситуация меняется, когда данные нужно обрабатывать, то есть когда выделяются такие вот сущности типа Customer->Orders->OrderItems->Product->Vendor... ->Region, и эти сущности нужно редактировать, передавать их как параметры,

О! Вот именно в таких сценариях, каждый лишний метод в данных — повод к геморрою.

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

Так именно об этом я и толкую. Добавлять этот функционал нужно не к данным, а к внешним сервисам.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 20.11.08 15:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Пусть возьмут на работу создателя Hibernate — он может им расскажет как не надо делать

Ка не надо делать — знают все, никто не знает как надо...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
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[14]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 28.11.08 01:27
Оценка:
Здравствуйте, IB, Вы писали:

IB>Именно... Фишка-то ровно в том, что если присмотреться к типичному приложению, которое активно использует БД, то там процентов 90-95 работы — это отчеты. Список товаров в заказе — отчет, история заказов — отчет, адреса доставки — отчет, ect...

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

ST>>Однако, ситуация меняется, когда данные нужно обрабатывать, то есть когда выделяются такие вот сущности типа Customer->Orders->OrderItems->Product->Vendor... ->Region, и эти сущности нужно редактировать, передавать их как параметры,

IB>О! Вот именно в таких сценариях, каждый лишний метод в данных — повод к геморрою.
Где ты тут увидел методы, кстати?

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

IB>Так именно об этом я и толкую. Добавлять этот функционал нужно не к данным, а к внешним сервисам.
Угу, и получить помойку сервисов.
Sapienti sat!
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 28.11.08 09:44
Оценка:
Здравствуйте, Gaperton, Вы писали:

Gaperton, а можно где нить об этом почитать? На уровне "программиста-домохозяйки".
Тема очень интересная, но я в ней ни бум-бум.

СУВ, Aikin
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 28.11.08 10:38
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это как раз не отчёты.

Именно что отчеты, в чистом виде.

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

Не реализуется, потому что эти связи там лишние.

C>Где ты тут увидел методы, кстати?

Я не увидел, я говорю, что они там не нужны.

C>Угу, и получить помойку сервисов.

Счегобыс?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 11:05
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Gaperton, а можно где нить об этом почитать? На уровне "программиста-домохозяйки".

A>Тема очень интересная, но я в ней ни бум-бум.

Можно, но источник неожиданный, и вынести знакомство с ним без повреждения мозга способен не каждый. Посмотри, как устроено 1С:Предприятие 8, модуль торговля+склад или как он там называется. Там вся база делается на трех классах объектов — справочник (статический объект), документ (соответствует действию, имеет время и может двигать "регистры"), "регистр" (похоже на OLAP-звезду, по нему можно строить отчеты и снимать с него в реальном времени, скажем, остатки). Бухгалтерию и все остальное смотреть не надо — это мимо. Потом — найди сайт CouchDB, и прикинь, как туда ляжет модель "справочник-документ-отчет".
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 28.11.08 11:17
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

Занятно. Спасибо, посмотрю.
...
Залез в Гугл -- инет забит рекламой. Если не сложно (в пределах 2-х, 3-х кликов), можно ли меня "ткнуть носом" описание?
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Cyberax Марс  
Дата: 28.11.08 19:31
Оценка:
Здравствуйте, IB, Вы писали:

C>>Это как раз не отчёты.

IB>Именно что отчеты, в чистом виде.
Нет. Тогда и вот такое можно считать отчётом:
public void print(Country contry)
{
   for(State st : country)
       System.out.println(st.getName());
}


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

IB>Не реализуется, потому что эти связи там лишние.
Реализуется. Смотрим на 1С.

C>>Угу, и получить помойку сервисов.

IB>Счегобыс?
Стогобыс. Очень много мелких сервисов получится.
Sapienti sat!
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.11.08 21:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Реализуется. Смотрим на 1С.


Смотрим на нормальные конфигурации и убеждаемся, что там в основном используют запросы либо вшитый в платформу функционал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1115 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 29.11.08 11:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет. Тогда и вот такое можно считать отчётом:

А чем это не отчет?

C>Стогобыс. Очень много мелких сервисов получится.

Вот прям так, без вариантов?
Не получится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 29.11.08 11:21
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Поэтому, на практике при таком подходе получается, что тебе чаще всего просто не нужна способность реляционной модели натягивать иерархию с любой точки. Ты платишь за это избыточностью информации, примерно двукратной. Зато приобретаешь очень интересные полезные свойства. Например, у тебя элементарно все быстрее работает, за счет того, что join-ов стало меньше.

Ну, так это все относится именно к организации данных в хранилище, а не к тому, как я на это дело объекты натянул, чтобы отчеты построить и логику навернуть. Объекты опять-таки будут похожи на то, что у меня в хранилище лежит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 03.12.08 00:03
Оценка:
Здравствуйте, IB, Вы писали:

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


G>>Поэтому, на практике при таком подходе получается, что тебе чаще всего просто не нужна способность реляционной модели натягивать иерархию с любой точки. Ты платишь за это избыточностью информации, примерно двукратной. Зато приобретаешь очень интересные полезные свойства. Например, у тебя элементарно все быстрее работает, за счет того, что join-ов стало меньше.

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

Это относится и к тому и к другому. Приведенная модель — это довольно сильное ограничение на объектную модель, и ее отображение в хранилище. Следуя этому ограничению, ты проектируешь систему сразу в терминах "документов", "справочников", и "регистров", избегая традиционной модели "сущность-связь". То есть, ты очень сильно себя ограничиваешь. Делается это заради получения некоторых полезных свойств.
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[19]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 03.12.08 08:08
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

Вчера скачал пару книг. Но так до них и не добрался.

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

Мне не нужно "как это устроено в 1С" мне нужны принципы.

G>Примерно все. Понятно, как работает?

Издеваешься? Куча новых появилось

G>Вообще, все очень просто. Система построена на нескольких простых принципах — рассказываю про 7.7.

Из всего что ты написал меня интересовало:
1) Регистры (самая важная для меня часть системы) хранятся в виде OLAP-звезды // надо мне поближе с этим понятием познакомиться, полгода назад читанул пару статей, получил общие сведения и все. Нужно вернуться еще раз.
2) Не совсем понял что такое Документ // ...
3) Все изменения в документах сопровождаются добавлением регистров // тут отдельный вопрос: какая служебная информация хранится в регистре для идентефикации операции; как достигается атомарность операции, только транзакциями или есть еще какой механизм.
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.12.08 09:24
Оценка:
Здравствуйте, Aikin, Вы писали:

A>2) Не совсем понял что такое Документ // ...


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

A>3) Все изменения в документах сопровождаются добавлением регистров


Не обязательно, но как правило.

A> // тут отдельный вопрос: какая служебная информация хранится в регистре для идентефикации операции;


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

A> как достигается атомарность операции, только транзакциями или есть еще какой механизм.


В 7.7 — тупые эксклюзивные блокировки таблиц целиком на основе блокировки файлов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 03.12.08 09:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Персистентная сущность с датой, номером, табличной частью и набором произвольных атрибутов. Кроме того, при изменении/добавлении/удалении есть автоматически вызываемые функции, которые могут выполнять запись в регистры. Откат производится автоматически.

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

A>> // тут отдельный вопрос: какая служебная информация хранится в регистре для идентефикации операции;

AVK>Что ты понимаешь под операцией?
Любое действие над Документом в ходе которого создан регистр.

A>> как достигается атомарность операции, только транзакциями или есть еще какой механизм.

AVK>В 7.7 — тупые эксклюзивные блокировки таблиц целиком на основе блокировки файлов.
Ясно.
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.12.08 09:45
Оценка:
Здравствуйте, Aikin, Вы писали:

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


Набор подчиненных персистентных объектов, представляющих строки документа.

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

A>Любое действие над Документом в ходе которого создан регистр.

Поскольку действие там ровно одно — проведение, то и идентификаторов никаких не надо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 03.12.08 10:59
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

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

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

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


А правильно ли будет провести анлогию в VCS: Документ == файл под контролем, Регистр == набор изменений для конкретного файла?
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[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 03.12.08 11:21
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>Я тоже не разбираюсь в 1С, но я это понял немного по другому. У нас есть Регистр(в "ревизии" 0). Над ним произвели 5 проводок (получился Регистр в "ревизии" 5). Эти 5 проводок представлены 5-ю Документами.

А я понял в точности наоборот
Да и OLAP-звезды строятся именно по протянутым во времени сущностями, сохраняя каждую их версию.
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.12.08 11:34
Оценка:
Здравствуйте, Aikin, Вы писали:

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


Это по тебе. А по мнению авторов 1С — нет.

AVK>>Поскольку действие там ровно одно — проведение, то и идентификаторов никаких не надо.

A>Ну вот смотри. У нас есть Документ (в "ревизии" 0). Над ним произвели 5 действий (получился документ в "ревизии" 5). Эти 5 действий представлены 5-ю Регистрами.

Ничего не понял. Какие, нафик ревизии и какие 5 регистров? При каждом изменении документа все записи во всех регистрах, связанных с ним, удаляются. При повторном проведении — добавляются по новой. Никаких ревизий.

A> Как минимум у регистра есть Id документа


Есть

A> и номер "ревизии" в которой Документ был изменен


Нету. Есть только дата проведения.

A> (он же задает последовательность применения Регистров к документу).


Нет, не задает. Последовательность задает прикладной программист руками.

A>А правильно ли будет провести анлогию в VCS: Документ == файл под контролем, Регистр == набор изменений для конкретного файла?


Нет. Ты вообще, хотя бы примерно, представляешь себе, что такое OLAP/OLTP кубы?
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: Константин Б. Россия  
Дата: 03.12.08 11:38
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, Константин Б., Вы писали:


КБ>>Я тоже не разбираюсь в 1С, но я это понял немного по другому. У нас есть Регистр(в "ревизии" 0). Над ним произвели 5 проводок (получился Регистр в "ревизии" 5). Эти 5 проводок представлены 5-ю Документами.

A>А я понял в точности наоборот
A>Да и OLAP-звезды строятся именно по протянутым во времени сущностями, сохраняя каждую их версию.

Ну.

3) Регистры являются почти классической OLAP-звездой, с тем исключением, что позволяют моментально брать остатки на текущий момент.

Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Aikin Беларусь kavaleu.ru
Дата: 03.12.08 11:42
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Поскольку действие там ровно одно — проведение, то и идентификаторов никаких не надо.

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

A>>А правильно ли будет провести анлогию в VCS: Документ == файл под контролем, Регистр == набор изменений для конкретного файла?

AVK>Нет. Ты вообще, хотя бы примерно, представляешь себе, что такое OLAP/OLTP кубы?
Примерно -- да
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 05.12.08 11:26
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>Это по тебе. А по мнению авторов 1С — нет.


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

AVK>>>Поскольку действие там ровно одно — проведение, то и идентификаторов никаких не надо.

A>>Ну вот смотри. У нас есть Документ (в "ревизии" 0). Над ним произвели 5 действий (получился документ в "ревизии" 5). Эти 5 действий представлены 5-ю Регистрами.

AVK>Ничего не понял. Какие, нафик ревизии и какие 5 регистров? При каждом изменении документа все записи во всех регистрах, связанных с ним, удаляются. При повторном проведении — добавляются по новой. Никаких ревизий.


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

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

Кстати, еще одна крутая придумка 1С-ников. Вы можете ввести документ "на основании" любого другого, в этом случае при его создании отработает "конструктор копировая", который вы сами пишете. Workflow изображается элементарно — в визуальную форму документа, который соответствует состоянию workflow, добавляются кнопки "вводов на основании", которые позволяют из него перейти к следующему действию. Есть еще варианты.
Re[26]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.12.08 13:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ну да, надо добавить, что никто действий над документами не производит. Сам документ — это действие.


Не совсем так. Сам документ в 1С все таки очень часто 1 в 1 соответствует реальному бумажному документу. То, о чем ты говоришь, есть в других системах, там основой является как раз таки действие (например бухгалтерская проводка), а документ может даже восстанавливаться на основе проводок. В 1С же все наоборот, документы первичны, действия вторичны.

G>Кстати, еще одна крутая придумка 1С-ников. Вы можете ввести документ "на основании" любого другого


Это не 1С придумал, эта фича есть в куче другого управленческого софта.

G> Workflow изображается элементарно — в визуальную форму документа, который соответствует состоянию workflow, добавляются кнопки "вводов на основании"


В реальных системах все может быть намного круче и гибче, чем в 1С. См. например "процессный подход".
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
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[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.12.08 15:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


G>>Ну да, надо добавить, что никто действий над документами не производит. Сам документ — это действие.


AVK>Не совсем так. Сам документ в 1С все таки очень часто 1 в 1 соответствует реальному бумажному документу. То, о чем ты говоришь, есть в других системах, там основой является как раз таки действие (например бухгалтерская проводка), а документ может даже восстанавливаться на основе проводок. В 1С же все наоборот, документы первичны, действия вторичны.


В 8 есть документ отображения регистра, а для проводок существует операция. Но так или иначе это документы, но содержимое отображается в регистры (бух итоги) без преобразования.
и солнце б утром не вставало, когда бы не было меня
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 05.12.08 16:56
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


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


S>Главное что бы операторы по Русски. На каком языке думаю на том и пишу.


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

> А по поводу составных документов то и на 7.7 это несложно делать.


Технически — да. Однако, были определенные проблемы с организацией ГУЯ, связанные с тем, что в документе и элементе справочника нельзя было вляпать произвольную табличную часть. С появлением контрола таблицы выкрутится можно было всегда, но это было связано с лишением халявы, в виде автоматического data binding, который надо было делать в ручную. А я, когда программил на 1С, очень не любил лишаться халявы — 1С тем и крут, что persistence и data binding полностью автоматический. Когда приходится таблицы руками наполнять — не по 1С-сному это как-то получается, некошерно. Обычно, я предпочитал изменить модель данных, чтобы избежать ручного binding-а.
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
От: Gaperton http://gaperton.livejournal.com
Дата: 05.12.08 19:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:

G>>Ну да, надо добавить, что никто действий над документами не производит. Сам документ — это действие.


AVK>Не совсем так. Сам документ в 1С все таки очень часто 1 в 1 соответствует реальному бумажному документу.


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

Чтобы скрыть это с глаз долой, в случае многошагового процесса можно сделать "составной документ". То есть, завести главный документ, в котором отображать статус, и вводить шаги на его основании (один шаг — один документ), проводя их поотдельности "за сценой". Я так делал.

AVK>То, о чем ты говоришь, есть в других системах, там основой является как раз таки действие (например бухгалтерская проводка), а документ может даже восстанавливаться на основе проводок. В 1С же все наоборот, документы первичны, действия вторичны.


ИМХО, в 1С сделали правильный выбор. Так удобно. Если надо — то бить документы на отдельные документы, которые проводятся группой — можно, и ничего страшного в этом нет.

G>>Кстати, еще одна крутая придумка 1С-ников. Вы можете ввести документ "на основании" любого другого


AVK>Это не 1С придумал, эта фича есть в куче другого управленческого софта.


Вполне возможно. Даже наверняка.

G>> Workflow изображается элементарно — в визуальную форму документа, который соответствует состоянию workflow, добавляются кнопки "вводов на основании"


AVK>В реальных системах все может быть намного круче и гибче, чем в 1С. См. например "процессный подход".


С удовольствием посмотрю, особенно если ты дашь ссылку. Сдается мне, по сочетанию "процессный подход" не так просто что-либо конкретное найти.
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.12.08 09:06
Оценка:
Здравствуйте, Gaperton, Вы писали:


>> А по поводу составных документов то и на 7.7 это несложно делать.


G>Технически — да. Однако, были определенные проблемы с организацией ГУЯ, связанные с тем, что в документе и элементе справочника нельзя было вляпать произвольную табличную часть. С появлением контрола таблицы выкрутится можно было всегда, но это было связано с лишением халявы, в виде автоматического data binding, который надо было делать в ручную. А я, когда программил на 1С, очень не любил лишаться халявы — 1С тем и крут, что persistence и data binding полностью автоматический. Когда приходится таблицы руками наполнять — не по 1С-сному это как-то получается, некошерно. Обычно, я предпочитал изменить модель данных, чтобы избежать ручного binding-а.

Я это к тому, что до сих пор сижу на 7.7, а смысла особого напереходить на 8 нет на предприятии где работаю нет (а за новшества я двумя руками за). Вернее смысл есть, только не стоит это тех трудозатрат на переход.
Просто недавно нужно было сделать в одном документе трёх уровневое подчинение в документе. Через Тз это решается, и если данные однотипны , то документ практически хранит одни данные. Это так к слову. Приходится выкручиваться, для удобства пользователей, а они ещё и не ценят. Иногда даже полезно лишаться халявы, для тренировки мозгов. Да и как шаблон такой документ можно использовать многократно. А так я давно жду новый компилируемый виток 1С, хотя скорости то хватает, а там где ее нет прямой доступ и Вк (для Sql прямыми запросами вытащить данные, а на клиенте уже обработать, хотя и 1С++ во многом хватает).
Для SQL жду недождусь когда же можно применять объектный подход на стороне сервера. Тогда системы типа 1С могли бы работать с огромным количеством юзеров. Потому, что так или иначе объектный подход к развитым по структуре хранилищам данных, имеющие неопределенные типы данных (Справочник, документ итд). А работаю, я все на 1С 7.7
и солнце б утром не вставало, когда бы не было меня
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.12.08 11:43
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>С удовольствием посмотрю, особенно если ты дашь ссылку. Сдается мне, по сочетанию "процессный подход" не так просто что-либо конкретное найти.


К сожалению, ссылок я не коллекционирую, поскольку данная тема находится за пределами моей компетенции. Единственная ссылка, какая у меня есть — http://www.parus.ru/index.php?page=276
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[33]: Взаимодействие с Базой Данных из C# по схеме MS
От: michael_isu Беларусь  
Дата: 03.03.09 21:27
Оценка:
Здравствуйте, IB, Вы писали:

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


C>>А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай.

IB>Чтобы не пришлось, надо не насвистывать, а явно открывать и закрывать соединение с базой при каждом обращении — дешево и сердито, и никакой ручной синхронизации потоков с приседаниями вокруг сессий.

Делаю сейчас модуль онлайн-тестирования студентов. В текущей схеме есть целый граф объектов, часть из которых грузится лениво, часть — явно. Чтобы по нескольку раз не дергать СУБД, однажды загруженные данные сохраняются в сессии (вопросы тестирования, ответы и т.д.). Это более медленный и кривой вариант, чем если бы за каждым элементом данных приходилось лезть в БД снова и снова?
Re[34]: Взаимодействие с Базой Данных из C# по схеме MS
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.03.09 06:09
Оценка:
Здравствуйте, michael_isu, Вы писали:

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


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


C>>>А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай.

IB>>Чтобы не пришлось, надо не насвистывать, а явно открывать и закрывать соединение с базой при каждом обращении — дешево и сердито, и никакой ручной синхронизации потоков с приседаниями вокруг сессий.

_>Делаю сейчас модуль онлайн-тестирования студентов. В текущей схеме есть целый граф объектов, часть из которых грузится лениво, часть — явно. Чтобы по нескольку раз не дергать СУБД, однажды загруженные данные сохраняются в сессии (вопросы тестирования, ответы и т.д.). Это более медленный и кривой вариант, чем если бы за каждым элементом данных приходилось лезть в БД снова и снова?

Используя сессию вы значительно уменьшаете scalability своего приложения. Это касается даже не кластеризации, когда приложение разворачивается более чем на одном компе, а банального shared хостинга. С увеличением числа пользователей объем хранимых сессий постоянно растет и вы рискуете вылететь за ограничения, что потребует от вас больших расходов.

Кроме того вопросы и ответы не зависят от пользователя который работает в данный момент, то почему используется сессия, а не какой-нить in-process cache?

Кстати, почему не использовано HTTP кеширование?
Re[35]: Взаимодействие с Базой Данных из C# по схеме MS
От: michael_isu Беларусь  
Дата: 04.03.09 07:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Используя сессию вы значительно уменьшаете scalability своего приложения. Это касается даже не кластеризации, когда приложение разворачивается более чем на одном компе, а банального shared хостинга. С увеличением числа пользователей объем хранимых сессий постоянно растет и вы рискуете вылететь за ограничения, что потребует от вас больших расходов.

G>Кроме того вопросы и ответы не зависят от пользователя который работает в данный момент, то почему используется сессия, а не какой-нить in-process cache?

Потому что не до конца продумал архитектуру. Есть набор классов данных (допустим вопросы и ответы), к каждому вопросу привязано несколько ответов. следуя принципу SRP (если я его правильно понимаю), в классах содержатся только те данные, которые соответствуют классу. Соотв. в класс Вопрос я уже не могу положить коллекцию из ответов, которые ему соответствуют, поэтому связь этих объектов должна быть куда-то вынесена. Куда вынесена и как с ней работать пока непонятно.. (.NET 2.0) Какие есть идеи?

G>Кстати, почему не использовано HTTP кеширование?


потому что не открыл для себя ещё этот термин
Re[30]: Взаимодействие с Базой Данных из C# по схеме MS
От: vdimas Россия  
Дата: 10.03.09 18:09
Оценка:
Здравствуйте, Cyberax, Вы писали:


S>>Ее можно эмулировать на SQL без особых проблем. Тем не менее, SQL достаточно сильно отличается от "классической" РА, и именно потому, что "инженерные" соображения оказались важнее, чем 100% соответствие.

C>Он очень к ней близок.

Да задачи разные, о чём тут спорить? В SQL я не могу указать как именно мне получить результат, я лишь могу указать, что я хочу получить. В большинстве случаев декларативный запрос гораздо короче (для того его и разрабатывали), но некоторые простые операции из РА в SQL выглядят монстрообразно.
... << RSDN@Home 1.2.0 alpha rev. 786>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.