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

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

Я изучаю значения слов, а не звучание. Ты несколько раз употребил слово масштабируемость совершенно не в тему. Я полагаю, что ты считаешь свои сообщения более умными если там есть умное слово. Это не так.
Вобщем завязывай. Я привёл и примеры ошибочных действий в случае когда нет ХП и примеры данных для которых реляционная и объектная модель сильно различаются и вообще много чего существенного сказал. Ты же толчёшь воду в ступе. В твоих сообщениях нет решительно ничего полезного. Охи и вздохи оставь себе, мне их случать не интересно.

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


A>Я изучаю значения слов, а не звучание. Ты несколько раз употребил слово масштабируемость совершенно не в тему. Я полагаю, что ты считаешь свои сообщения более умными если там есть умное слово. Это не так.
A>Вобщем завязывай. Я привёл и примеры ошибочных действий в случае когда нет ХП и примеры данных для которых реляционная и объектная модель сильно различаются и вообще много чего существенного сказал. Ты же толчёшь воду в ступе. В твоих сообщениях нет решительно ничего полезного. Охи и вздохи оставь себе, мне их случать не интересно.

Где? Примеры где?

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

A>>>Ты меня утомил, отстань и делай что хочешь. Пока мы работаем не вместе, мне плевать.
kuj>>Значит ответить на вопрос как и чем Вы тестируете БД не можем никак? Все понятно.

A>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.


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

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

kuj>Где? Примеры где?

http://www.rsdn.ru/Forum/message/2667683.1.aspx

Автор: adontz
Дата: 24.09.07

http://www.rsdn.ru/Forum/message/2669221.1.aspx

Автор: adontz
Дата: 25.09.07

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

kuj>Мы говорим о корпоративных БД? Для корпоративных БД ORM подход зарекомендовал себя как лучший на протяжении уже многих лет в тысячах, в десятках тысяч проектов по всему миру.

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

kuj>Особенно смешно это читать про Java... Еще один перл в коллекции.

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

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

C>>Не понял сути. Можно подробнее немного?
A>Анкета медицинского обследования
A>Пол? [Мужской] [Женский]
A>Рука дёргается? [Да] [Иногда] [Нет]
A>Глаза слезятся? [Да] [Иногда] [Нет]
A>получаем 2*3*3 = 18 вариантов.
A>Итого имеем 18 вариантов реакции (текст в рекомендациями). В программе снимок текущей системы вопросов в виде List<Diagnoses>, в БД этого естествено нет. Список вопросов не статичный, со временем может менятся их набор, порядок, варианты ответов. То есть хранить БД всё в таблице (int, string) не получается.
Ага, ты нашел самую гадостную для РБД вещь Объясняющую, кстати, большое распространение объектных баз данных в медицинских системах.

На РБД это можно сделать таким образом:
1) Если список вопросов достаточно статичный — то просто делаем таблицу с колонкой на каждый вопрос. Набор колонок отображаем в List<Diagnosis> в DAL. Самое быстрое решение будет, кстати. Но при добавлении вопроса — придется менять схему.
2) Делаем полиморфное отношение с join-таблицами и полем-дискриминатором. Масштабироваться будет достаточно неплохо, но не неограничено.
3) Если набор типов вариантов ответа и типов вопроса ограничен — то делаем простую табличку:

CREATE TABLE "public"."question" (
  "id" BIGINT NOT NULL, 
  "question_id" BIGINT, 
  "answer_id" BIGINT, 
  CONSTRAINT "question_pkey" PRIMARY KEY("id")
);

Где question_id — ссылка на сущность в словаре запросов (тут тоже хорошо полиморфные отношения подойдут), а answer_id — ссылка на ответ.
4) Комбинированое решение — самые частые вопросы добавлять в таблицу колонками, а экзотику — в виде дополнительных отношений.
5) Завтра еще у нашего DBA спрошу что еще можно сделать

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

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

A>>>>Это какая-то неправильная хранимка, она значит что-то лишнее делает.
A>>Многоуважаемый adontz. Язык T-SQL является процедурным языком. Может Вы имеете в виду вашу собственную разработу декларативного языка для СУБД?

A>SQL это декларативный язык. T-SQL декларативный язык с императивными элементами. Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.
Я нифига понял из написанного . То есть в С все пишут планы запросов или это декларативный язык?

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

A>>ЗЫ Если серьёзно, то это очередный аргумент, что связываться с mysql не стоит.

A>100%. Но его бесплатность и популярность делают своё чёрное дело. Я вообще не думаю, что после выхода Express версий с чем-то кроме MSSQL/Oracle стоит связываться. Себе дороже.
Тебя может это удивить, но ещё есть такие вещи, как Firebird

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

kuj>>Где? Примеры где?

A>http://www.rsdn.ru/Forum/message/2667683.1.aspx

Автор: adontz
Дата: 24.09.07

Прекрасный пример! В котором Вы предлагаете индексировать поле password (перл!), а потом приводите пример процедур, которые в виде методов должны находиться в DAL.

A>http://www.rsdn.ru/Forum/message/2669221.1.aspx

Автор: adontz
Дата: 25.09.07

Еще один чудесный пример. Называется "я ничего не знаю про словари и кеш второго уровня Hibernate".

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

A>>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.

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

Не надо принимать делаемое за действительное. На протяжении всего спора ты нёс полнеёший бред, начав с того что спор использовать или нет SP, ты перевёл в русло ORM vs SP. Все твои аргументы сводились к тому что я якобы чего-то не знаю, хотя "правильную" точку зрения ты так и не смог сформулировать. Хотя, конечно, заявления что SQL не декларативный язык и что бизнес-транзакций не существует ещё надолго запомнятся. Я понимаю, когда люди спорят о чём-то новом и не известном, но когда начинают определять факты данные по определению это просто утомляет.

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

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

K>>1) Как реализации ORM будут работать с MySQL? Например в последнем приложении я использую MySQL. Т.е. вообще для какой СУБД генерируются запросы? Простите если чего-то не понимаю.

A>Практически к любой ORM можно прикрутить поддержку практически любой БД.
Да, може тогда поможете мне прикрутить поддержку диалекта FB к одному из симпатичных мапперов без данной поддержки?

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

A>>>>>Это какая-то неправильная хранимка, она значит что-то лишнее делает.
A>>>Многоуважаемый adontz. Язык T-SQL является процедурным языком. Может Вы имеете в виду вашу собственную разработу декларативного языка для СУБД?

A>>SQL это декларативный язык. T-SQL декларативный язык с императивными элементами. Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.
A>Я нифига понял из написанного . То есть в С все пишут планы запросов или это декларативный язык?

С это очевидно Непонятно хто с императивными элементами.

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

C>Ага, ты нашел самую гадостную для РБД вещь

Она меня сама нашла несколько лет назад. Причём меня тогда поразило то что я не то чтобы не смог с наскоку сделать хоть как-то, а то что я с наскоку вообще ничего не смог сделать. Пришлось задуматся. А потом я начал понимать, что БД и объекты совсем разные вещи и разрабатывать их надо отдельно.

C>2) Делаем полиморфное отношение с join-таблицами и полем-дискриминатором. Масштабироваться будет достаточно неплохо, но не неограничено.

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

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

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

A>>>Ты меня утомил, отстань и делай что хочешь. Пока мы работаем не вместе, мне плевать.
kuj>>Значит ответить на вопрос как и чем Вы тестируете БД не можем никак? Все понятно.

A>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.
Был задан очень хороший и вполне конкретный вопрос. Причём этот вопрос задавался неоднократно по этой теме. Ты сказал что тестируешь ХП и БД. Общественность заинтересовалась как ты это делаешь. У меня вот, например, так и не получилось , так что я с удовольствием почитаю как.

Здравствуйте, kuj, Вы писали:
kuj>Бизнес-логика ничего. Абсолютно ничего о транзакциях знать не должна. Для этого есть DAL, который управляет транзакциями, где это необходимо.
Ну, лично мне это странно слышать. Есть, конечно, "технические" транзакции (типа коммит после каждой записи лога, чтобы обеспечить максимум информации в случае сбоя), но в основном "ноги" у транзакций растут именно из бизнеса. Сам бизнес рассматривается как набор процессов, которые представляют собой цепочки транзакций.
При этом в бизнес-транзакцию в отличие от того, что происходит по begin tran, может включаться много всяких ресурсов. Например, транзакция "обработка заказа" может включать в себя, помимо записи чего-то в базу, поиск товара на складе, упаковку его в тару и передачу в транспортную компанию, а также отправку емейла. И всё это должно удовлетворять требованиям ACID. Именно бизнес определяет, не поделить ли этот процесс на другие транзакции — например, для оптимизации выделить передачу в транспортную компанию в отдельную транзакцию.

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

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

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

A>>SQL — декларативный язык.

kuj>Кстати говоря, SQL это ни разу не декларативный язык. SQL это информационно-логический язык и по-сути он не является языком программирования. SQL это структурированный язык запросов.
kuj>Декларативный язык это, например, Prolog.
Я с вас обоих угораю.
Пришли значит, две генеральские жены в оперу. Отслушали первый акт. Первая:
— Нет, это просто фураж!
Вторая:
— Ты что, дура? Не фураж, а террор!

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

Более того, Пролог тоже является информационно-логическим языком, если говорить о более формальной классификации.

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

A>Народ, мне лень уже. Ничего нового сказано уже, наверное, не будет.
A>Спасибо Cyberax, как единственному опоненту с которым было интересно поболтать. Я может в чём-то и не согласен, но он по крайней мере не фанатик.
A>Остальным тоже спасибо, было весело.
A>Всем удачного вторника.
тебе тож спасибо, ты был на высоте. давно я так не смеялся от души.

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


kuj>>Мы говорим о корпоративных БД? Для корпоративных БД ORM подход зарекомендовал себя как лучший на протяжении уже многих лет в тысячах, в десятках тысяч проектов по всему миру.

I>Ну и хорошо, облегчение труда програмиста почти всегда благо. Только не надо думать, что нет многих лет использывания хранимых процедур и десятков тысяч проектов по всему миру...

В наше время? Готов поспорить, что нет, а те что есть в основном пережитки далекого прошлого.

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

kuj>>Особенно смешно это читать про Java... Еще один перл в коллекции.

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

Вы знаете как зарабатывать деньги на открытых проектах? Поделитесь знаниями! :D

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

A>>SQL это декларативный язык. T-SQL декларативный язык с императивными элементами. Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.
A>Я нифига понял из написанного . То есть в С все пишут планы запросов или это декларативный язык?

SQL — это декларативный язык. Ты описываешь не КАК делать, а ЧТО делать. Не способ получения конечного результата, а сам результат.

T-SQL это декларативный язык (старое-то не выкинули) с императивными элементами (новое добавили). То есть в некоторых случаях ты теперь можешь описать КАК получить результат. Причём это не замена уже существующим механизмам, а дополнение.

Наследования в каком-либо виде в T-SQL нет, пространств имён или класов — тоже. Императивная часть T-SQL не объектно-ориентирована, она процедурная.

Если бы T-SQL был чисто императивным процедурным языком, то тебе вместо декларативного описания результата запроса пришлось бы императивно определять план его исполнения. Этого не наблюдается.

Не знаю как ещё выразить свою мысль. Лучше конкретные вопросы задавай.

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

A>>http://www.rsdn.ru/Forum/message/2669221.1.aspx

Автор: adontz
Дата: 25.09.07

kuj>Еще один чудесный пример. Называется "я ничего не знаю про словари и кеш второго уровня Hibernate".

Чудно. А теперь покажи мне решение с кешом второго уровня. Я жду.