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

A>То ты, как адепт ОРМ, конечно же создашь таблицу с полями ID, Login, Password, FirstName, LastName. В нормальной, расширяемой БД такого не будет. Будет таблица Users (ID, Login, Password) и таблица UserProperties (UserID REFERENCES (Users.ID), PropertyName, PropertyValue). Это верное решение, потому что добавление полей в клас User никак не забрачивает схему БД, DAL и т.п.
Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.

A>Чтобы такие правильные решения принимать надо при построении БД плясать не от иерархии объектов, а от представляемых сущностей. Фактически ORM это зло, действительно правильно делать ROM, так как только в этом случае можно получить вменяемую БД, построенную как надо и не являющуюся жалкой тенью чужеродного ей понятия иерархии объектов. ООП в БД делать нечего, Entity-Relations описанные в ТЗ ложатся в БД один к одному, объекты — нет. объекты вторичны, ER — первичны и именно на их основе надо строить БД.
ER-диаграммы ОДИН-В-ОДИН (т.е. автоматически) могут переводится на объектную модель.

adontz
Не надоело минусы ставить? Не ну серьёзно, удивляет упорство, теперь я понимаю почему ты так защищаешь хранимки .

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

kuj>>>ХП vs запросы? О чем Вы?
AJD>>Хм. А о чем ветка? Разве не о преимуществах/недостатках использования ХП?
A>Нет, ветка у нас получалась Object-Relational Mappers против Хранимых Процедур.
Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.

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

A>Да что вы говорите . Вы статистику по проектам собирали или говорите на основании вашего горького опыта? Уже даже не смешно...

Просто не только складским учётом занимаюсь.

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

C>>Планы для "SELECT ... WHERE a.name='aa'" он тоже проверяет? А ведь таких тривиальных запросов — больше всего.
A>Нет, он пишет ХП план которой разбирает один раз. Остальные пользуются ХП с проверенным планом. вот для того и нужны ХП, что это гарантированный способ не напортачить.
Ну вот пусть спокойно пишет его и вставляет как именованый запрос в hbm.xml-файл (файл мэппинга). Только вот нужно это крайне редко.

C>>Т.е. разработчики будут стучать головой об стену, пока программисты БД не соизволят написать нужный запрос? Действительно, так и получается — сам видел.
A>Значит БД плохо расширяемая если на каждый чихз надо новый запрос писать. Пример про таблицы Users и Users-UserProperties я уже привёл.
БД расширяется прекрасно. Но у тебя запросы же отдельные люди пишут — а нужно это постоянно.

Про пример User/UserDetails — могу для тебя скринкаст сделать как я могу сделать рефакторинг из одного класса User.

A>>>Вполне сможет, если оно написано на уровне Entity-Relations.
C>>Ага, кончено. А модель в виде готовой схемы БД от аналитика он так вообще хорошо может понять.
A>Я всегда требую описания ER, иначе это не ТЗ, а филькина грамота.
Везет некоторым...

C>>Для тебя будет сюрпризом, но ER-диаграммы прекрасно ложатся на объектную модель.
A>Далеко не всегда. У БД с этим намного лучше.
Везде. Классические ER-диаграммы автоматически на объекты отображаются (собственно, куча MDA-тулзов только и занимаются этим).

C>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?
A>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?
Если не учитывать поведение объектов — всегда данные. Но не всегда красиво ложатся на реляционную модель.

C>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.
A>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.
Что значит "не вовремя"?

C>>Ага, вот только обычно от DBA получаются далеко не самые удобные для использования схемы (типа с эмуляцией наследования с помощью CASE'ов).
A>Это уже мои проблемы, его дело эффективность. Можно найти компромисс, но БД первична и не должна строится на основе иерархии объектов.
Прекрасно — вот тебе колоночная DB на K. Писать программы тоже только на K. Будешь?

A>Хммм... может у вас DBA нормальных нет? Вот и обходитесь другими стредствами? Я-то с монстрами работал, повезло конечно, вот и привык доверять. ХЗ, конечно всегда надо исходить из квалификации тех с кем работаешь, но у меня таких проблем точно не было.
Вроде нормальный — запросы оптимизирует очень круто.

C>>Нет, нужно проектировать систему так, чтобы добавление столбцов ничего не ломало (или ломало как можно быстрее). А не надеятся на внимание одного человек.
A>Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов
Это обычно нереально

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

C>Видимо, ты никогда не видел: http://tangosol.com/coherence-overview.jsp — кластерный транзакционный кэш, легко масштабируется на десятки машин (но стоит денег, сволочь). Сейчас используем тупой JBoss Cache — на кластере из пяти машин все спокойно живет, даже 100MBit не заполняет.

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

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

Кеш вообще штука хорошая, просто опасная.

A>>Программисты использующие ХП, читают, естесвенно, не весь код не ХП, а только описание (declaration).
C>Ага, а в коде ХП ошибок ну вообще никогда не бывает, конечно?

Меньше, чем в запросах написанных не DBA.

C>Ага, такие вредные привычки как легкорефакторируемый код и запросы. Например, вот так умеет новая IDEA:
C>

Нет, абсолютное забыванеи об индексах и представление, что объекты это точка отсчёта.

C>Hibernate генерирует абсолютно очевидный SQL. Что там такое у вас было??

Неочевидный SQL Я же говорю, БД и объекты очень сильно различались.

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

A>>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.
C>У меня вот два сервера БД (кластер с failover) и 3 app-сервера в качестве front-end'ов. Все прекрасно работает с Hibernate.

Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.

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

A>Видите ли, Ваша позиция напоминает программистов, которые в стародавние временна утверждали, что реальтный пацаны пишут на асме, где полный контроль машины, С для недоделанных. Дальше были дискуссии, что у Java/.NET нет будущего, на них приложения всегда будут проигрывать в эффективности С++... Время расставило всё на свои места.

Видишь ли, у меня много-много лет опыта работы за спиной и я знаю что панацеи нет и любая технология, самая хорошая вообще, обязательно облажается на какой-нибудь конкретной задаче. Hibernate это очень удобно и хорошо (кто бы спорил), но не всегда применимо. Без ХП писать можно, более того мелкие проекты нужно писать без ХП. В большинстве приложений не нужен MVC, достаточно Document-View. Вообще из пушки по воробьям стрелять не надо. Я реально сталкивался с задачами где реляционная модель и объекная раличались очень сильно и использоание ORM превращаось в мучение, в результате отказывались. Есть задачи не тестируемые автоматически в принципе, так что никакой TDD не спасёт. Вообще не надо верить в технологии, у них всегда есть область применения, зачастую довольно узкая.

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

C>Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.

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

C>ER-диаграммы ОДИН-В-ОДИН (т.е. автоматически) могут переводится на объектную модель.

Ну и как? Приличная модель выходит? Руками всё равно надо править...

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

A> Не надоело минусы ставить?

Минус выражает несогласие. В чём проблема? Если тебя это задевает лично, я могу убрать. Оценка вообще-то ставится сообщению, а не автору.

A>Не ну серьёзно, удивляет упорство, теперь я понимаю почему ты так защищаешь хранимки

ХП мне просто нравятся. Было долгое время, когда я писал без них. Я жестоко ошибался.

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

C>Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.

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

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

C>>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?
A>>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?
C>Если не учитывать поведение объектов — всегда данные. Но не всегда красиво ложатся на реляционную модель.

Скажем так, объекты не всегда entities. В реляционную модельне укладываются очень часто. Увы.

C>>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.
A>>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.
C>Что значит "не вовремя"?

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

C>Прекрасно — вот тебе колоночная DB на K. Писать программы тоже только на K. Будешь?

Что такое К?

A>>Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов
C>Это обычно нереально

Ну не каждый же чих...

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

A>Здравствуйте, Cyberax, Вы писали:
C>>Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.
A>А я к этому не призывал. Охотиться на ведьм можете в другом месте
Тем не менее, твои примеры ХП — это как раз пример DAL.

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

C>>Видимо, ты никогда не видел: http://tangosol.com/coherence-overview.jsp — кластерный транзакционный кэш, легко масштабируется на десятки машин (но стоит денег, сволочь). Сейчас используем тупой JBoss Cache — на кластере из пяти машин все спокойно живет, даже 100MBit не заполняет.
A>Этого действительно не видел. Суть проблемы это не меняет, неактуальный кеш — зло, эффективное поддержание кеша в актуальном состоянии — нетривиальная задача.
Для меня — тривиальная. Просто расставить '<cache usage="transactional"/>' в мэппинге. Остальное оно все само сделает (и делает!). Естественно, доступ к БД должен вестись только через Hibernate. Хотя в NHibernate есть инвалидация кэша по оповещениям от MSSQL — так что даже это ограничение снимается.

A>Кстати ненасыщенность 100Мбит это не показатель. Сравнивать надо это с физическим ограничением сети, а с трафиком к клиентам.
Клиенты ломятся через канал в 70Мбит с exchange'а на котором хостимся. Заполняют полностью в ЧНН.

A>>>Программисты использующие ХП, читают, естесвенно, не весь код не ХП, а только описание (declaration).
C>>Ага, а в коде ХП ошибок ну вообще никогда не бывает, конечно?
A>Меньше, чем в запросах написанных не DBA.
Не знаю, вряд ли.

C>>Ага, такие вредные привычки как легкорефакторируемый код и запросы. Например, вот так умеет новая IDEA:
C>>
A>Нет, абсолютное забыванеи об индексах и представление, что объекты это точка отсчёта.
А причем тут индексы? Они в mapping'е вообще не указываются, так как это деталь реализации, ей занимается DBA, которому нафиг не надо лазить в файлы mapping'а (разделение труда!).

C>>Hibernate генерирует абсолютно очевидный SQL. Что там такое у вас было??
A>Неочевидный SQL Я же говорю, БД и объекты очень сильно различались.
Может все-таки тогда стоило объектную модель подправить?

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

C>>Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.
A>Это надо делать не когда нужно, а на всякий случай. Именно это и отличает хорошего специальста, что он разрабатывает продукт не только для сегодняшнего дня, а с учётом возможных расширений.
Сразу ВСЕХ? А почему тогда явно указан password? А где секретный вопрос? А возможность использовать Kerberos куда дели? А почему не поддерживается OpenID?!!?!

C>>ER-диаграммы ОДИН-В-ОДИН (т.е. автоматически) могут переводится на объектную модель.
A>Ну и как? Приличная модель выходит? Руками всё равно надо править...
Обычно правки заключаются в добавлении явного наследования (там где это надо), приукрашению денормализованого представления и прочих мелочей.

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

A>>>Извини, мы не об опечатках. Я ни разу не видел, чтобы разработчик БД сам написал SELECT с кривым планом для БД разработанной им же. Он значит притворяется разработчиком БД если так.
C>>Планы для "SELECT ... WHERE a.name='aa'" он тоже проверяет? А ведь таких тривиальных запросов — больше всего.
A>Нет, он пишет ХП план которой разбирает один раз. Остальные пользуются ХП с проверенным планом.
Простите что пишет? План?

A>вот для того и нужны ХП, что это гарантированный способ не напортачить.
ХП это гарантированный способ не напортачить? Кто Вам эту чушь сказал?


C>>Т.е. разработчики будут стучать головой об стену, пока программисты БД не соизволят написать нужный запрос? Действительно, так и получается — сам видел.
A>Значит БД плохо расширяемая если на каждый чихз надо новый запрос писать.
Для того и нужны OR/M — чтоб не писать на каждый чих запрос.
A>Пример про таблицы Users и Users-UserProperties я уже привёл.
Вот, как это просто в случае с AR выглядит (таблицы Users — UserProperties — Properties):

Property p = new ...
p.Prop1 = ...;
p.Prop2 = ...;
...
p.Save();

User user = new ...
user.Properties.Add(p);
...

user.SaveAndFlush();

Будет автоматически сгенерирован пакет запросов SQL в виде INSERT`ов: первый в таблицу, на которую замаплен Property, второй в таблицу для User, третий в таблицу связи UserProperties.

теперь если что-то меняем. например, user.SomeProp = ...; user.SaveAndFlush(); то в этот раз будет сгенерирован UPDATE на конкретно поле (поля), на которое замаплено SomeProp.

Вся CRUD-логика автоматически в нашем полном распоряжении.

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


A>>>Вполне сможет, если оно написано на уровне Entity-Relations.
C>>Ага, кончено. А модель в виде готовой схемы БД от аналитика он так вообще хорошо может понять.

A>Я всегда требую описания ER, иначе это не ТЗ, а филькина грамота.

Зачем Вам ER-схемы, если Вы не занимаетесь DAL?

C>>Для тебя будет сюрпризом, но ER-диаграммы прекрасно ложатся на объектную модель.

A>Далеко не всегда. У БД с этим намного лучше.

Смешно.

C>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?

A>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?

Объект, а точнее класс — это совокупность данных и методов.

C>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.

A>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.

И это по-вашему мешает БД хранить данные?

C>>Ага, вот только обычно от DBA получаются далеко не самые удобные для использования схемы (типа с эмуляцией наследования с помощью CASE'ов).

A>Это уже мои проблемы, его дело эффективность. Можно найти компромисс, но БД первична и не должна строится на основе иерархии объектов.

Ну-ну... Как же Вы отстали от жизни...

C>>Кстати! Хорошее замечание, у нас была подобная проблема — неявная связь нескольких таблиц. В результате выловили несколько сложных ошибок, DBA забывали (по закону Мерфи!) синхронизировать таблицы (DBA ничего не заметил).
C>>В результате написали набор декларативных правил, которые теперь следят за целостностью системы.

A>Хммм... может у вас DBA нормальных нет? Вот и обходитесь другими стредствами? Я-то с монстрами работал, повезло конечно, вот и привык доверять. ХЗ, конечно всегда надо исходить из квалификации тех с кем работаешь, но у меня таких проблем точно не было.

Кадры приходят и уходят, а проекты остаются. Если Вы на столько полагаетесь на одного-двух разработчиков БД, то Ваши прожект-менеджеры, простите, полные идиоты. Как только они уволятся Вы все останетесь у разбитого корыта в виде громадного количества T-SQL кода со сложными зависимостями и почти полным отсутствием документации. Отствие же модульных тестов сделает рефакторинг задачей абсолютно из ряда фантастики... Вообщем удачи с таким допотопным подходом.

A>>>DBA не тормозит разработку как ты пытаешь представить, он не злой дядя-тормозун. Просто изменения большой системы с сохраненим её согласованности это конечно же куда более сложный и длительный процесс, чем написание "с нуля" как надо. Да, добавить столбец в таблицу оставив все запросы целостными может оказатся не просто. Но пусть этим занимается один человек, а иначе будут "сюрпризы".

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

A>Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов

Это фантастика. Требования постоянно меняются. Постоянно. Потому и выдумают различные agile-методы, tdd, ddd и прочие новомодные приемы и техники.

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

A>>>DBA должен плясать не от объектной модели, а от ER-диаграммы.
kuj>>Да ну? Кто Вам это сказал?

A>Так лучше выходит.

А я Вам скажу, что так выходит хуже. При чем гораздо хуже.

A>>>Нет, я всегда по мере возможности настаиваю чтобы БД разрабатывалась в первую очередь.
kuj>>Я бы хотел поинтересоваться, с чего Вы решили, что БД должна разрабатываться в первую очередь?

A>Скажем так, тут не столько важна хронология, сколько важно отсутствие влияния объектной модели на разработку БД.

Мда... я не завидую вашим разработчикам БД, но еще больше я не завидую вашим разработчикам BLL...

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


C>>>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?
A>>>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?
C>>Если не учитывать поведение объектов — всегда данные. Но не всегда красиво ложатся на реляционную модель.

A>Скажем так, объекты не всегда entities. В реляционную модельне укладываются очень часто. Увы.

Конечно... Если как Вы предлагаете — сначала делать схему БД, а потом пытаться на нее натянуть...

C>>>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.
A>>>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.
C>>Что значит "не вовремя"?

A>Не вовремя значит, что сперва сделали БД отражение иерархии объектов (по табличке на тип, по столбцу на поле) и решили что это хорошо. а потом вдруг выяснилось что так хранить данные крайне не эффективно.

А как их эффективно хранить? Просвятите нас неведающих...

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

kuj>>Наоборот тут речь о том, чтоб генерацией SQL-запросов занимался Hibernate (или т.п.), который прекрасно с этой задачей справляется, и в запросах, генерируемых Hibernate, Вы не увидете "*".

A>Это миф. В реальной системе соответствие поле_класса<->колонка_таблицы встречается достааточно редко! Hibernate просто не в состоянии автоматически построить подобные запросы.

Кто вам эту чушь сказал?

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

A>>>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
kuj>>Конечно не видете. Как же Вам видеть, если Вы вообще не понимаете о чем речь...

A>Давай я объясню просто, на примере. Если у тебя есть класс User вида
A>

A>class User
A>{
A>   public Guid ID {get;set};
A>   public string Login {get;set}
A>   public string FirstName {get;set}
A>   public string LastName {get;set}
A>   public ChangePassword(string oldPassword, string newPassword)
A>   ...
A>}
A>

A>То ты, как адепт ОРМ, конечно же создашь таблицу с полями ID, Login, Password, FirstName, LastName. В нормальной, расширяемой БД такого не будет. Будет таблица Users (ID, Login, Password) и таблица UserProperties (UserID REFERENCES (Users.ID), PropertyName, PropertyValue).
Интересно, а что мне помешает сделать то же самое в ORM? Думаете, я не смогу one-to-one relation в файле мэппинга прописать?

Вот еще один пример того, что делается элементарно в ORM. Т.н. nested type hieratchies — http://www.castleproject.org/activerecord/documentation/trunk/usersguide/typehierarchy.html

Хотел бы я посмотреть как Вы это запрограмируете на ХП.


A>Это верное решение, потому что добавление полей в клас User никак не забрачивает схему БД, DAL и т.п. Чтобы такие правильные решения принимать надо при построении БД плясать не от иерархии объектов, а от представляемых сущностей. Фактически ORM это зло, действительно правильно делать ROM, так как только в этом случае можно получить вменяемую БД, построенную как надо и не являющуюся жалкой тенью чужеродного ей понятия иерархии объектов. ООП в БД делать нечего, Entity-Relations описанные в ТЗ ложатся в БД один к одному, объекты — нет. объекты вторичны, ER — первичны и именно на их основе надо строить БД.

Зло это то, что Вы продолжаете спорить, ни капли не разбираясь в вопросе и даже не пытаясь разобраться.