SQL вопросик

[tpc]

Сообщение от svu

Сразу - не превратится. Но если тот же код Вы потом перепишете на pl/sql, у вас код потихоньку сживется с данными...

зуб даю - не срастется. конкретно если у меня жава фреймфорк wicket дергает pl/sql процедуры, вместо объектов хибера система не превратиться в 2-tier.

Сообщение от Kot

Тут есть ризон в нескольких вещах:
- тестирование (юнит тест для Оракла?),
- переносимость на клиентскую базу (клиенту не интересен Оракл, шо делать?),
- стоимость (масштабируемость того же ЖБосса обходится бесплатно, а можно еще распределенное кеширование юзать),
- простота управления кодом (дайте мне посмотреть на ИДЕ для ПЛ/СКЛь?),
- ...

- юнит тесты есть и для пл-скл (quest software), думаю и для жава в Jdeveloper должно быть.
- пл-скл никуда не перенесешь, жава может если пое.. то может что-то и удасться
- а вот тут все сложнее. у меня ощущение, что то что раньше работало на 4х процах с пл-скл оторваная логика в орм долбит субд так, что 4х процев субд уже не достаточно, а стоимость лицензий оракла ...
- ИДЕ под пл-скл как раз есть и есть хорошо навороченые, но в принципе согласен, красиво разложить код по пакетам пл-скл будет посложней, хотя жава со своими тараканами Rich vs Anemic ...

[svu]

Сообщение от tadpole

Наиболее просты в эксплуатации и поддержке тупые системы, написанные на клиент-сервер архитектуре а-ля 80-90-е.

Их невозможно развивать. Любая попытка расширить - трагедия.

Сообщение от tadpole

Убоги для чего?

Они убоги как языки программирования. Синтаксически и семантически. Там нет даже лямбды!

Сообщение от tadpole

Точно так же как отписывать обработку данных из C или Java с использованием JDBC какого-нибудь.

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

Сообщение от tadpole

который без приложения не имеет смысла.

"Алгоритмы + структуры данных = программы"

Сообщение от tadpole

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

Мне кажется, об этом не надо плакать. Это надо принять как данность. Как реальность. И затачивать методологии именно под такой образ действий.

Сообщение от AlexL

когда же потребовалось написать отчеты

А почему никто не подумал, что оперативная БД для приложения и БД для отчетов - могут быть разными?

svu добавил 02.05.2010 в 21:56

Сообщение от tpc

- юнит тесты есть и для пл-скл (quest software), думаю и для жава в Jdeveloper должно быть.

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

Сообщение от tpc

жава может если пое.. то может что-то и удасться

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

Сообщение от tpc

ИДЕ под пл-скл как раз есть и есть хорошо навороченые

Покажите мне поддержку рефакторинга в этих IDE.

[Kot]

Сообщение от tpc

оторваная логика в орм долбит субд так, что 4х процев субд уже не достаточно

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

Сообщение от tpc

красиво разложить код по пакетам пл-скл будет посложней

Дело не в красоте... "Код пишется не для босса, не за деньги и не для заказчика, он пишется для тех кто его будет сопровождать". Почитайте что такое рефакторинг.

Kot добавил 03.05.2010 в 00:28

Сообщение от tadpole

поддержание целостности в многопользовательской среде.

Целостности чего?.. "Когда вы хотите доехать вам шашечки нужны или средство передвижения?" Данные могут хранится де угодно, главное это не усложнять процесс их обработки.

Сообщение от tadpole

В чём соль комментария?

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

Не, правда, это разговор глухого с немым...

[tpc]

Сообщение от svu

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

последний раз ? давно это было, где-то за пару лет до появления жава, где-то в тот момент публично вздернули за яйца последнего кто решил протестировать в отрыве от данных.
для пл-скл юнит тесты выглядят так:
http://unittest.inside.quest.com/product_info.jspa

[tadpole]

Сообщение от Kot

Не, правда, это разговор глухого с немым...

Аминь.

[tpc]

Сообщение от Kot

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

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

Сообщение от Kot

Дело не в красоте... "Код пишется не для босса, не за деньги и не для заказчика, он пишется для тех кто его будет сопровождать". Почитайте что такое рефакторинг.

вы начинаете гнуть пальцы не понимая, о чем говорит опонент

[svu]

Сообщение от tpc

последнего кто решил протестировать в отрыве от данных.

Тестировать надо с данными. Обязательно. Но данные должны быть на входе теста в виде структур данных, а не в виде таблиц. Иначе вы тестируете одновременно хранилище и алгоритмы. Это, конечно же тесты. Безусловно полезные, даже возможно автоматизированные - но это НЕ юнит-тесты.

Спасибо за ссылку, любопытные картинки - но они только подтверждают то, что я ожидал - в мире plsql не может быть юнит тестов. Точнее, теоретически может, но за юнит-тестируемый код отрывают гениталии, как Вы любезно нам сообщили (ибо они действительно идут в разрез с принятым стилем разработки plsql)

И да, как там насчет рефакторинга в IDE?

svu добавил 03.05.2010 в 11:15

Сообщение от tpc

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

Что предлагаете? К сожалению, реляционные базы часть реальности. Как и желание разработчиков приложений использовать ОО. Я вижу единственный выход - делать ормы все более умными, чтобы их общение с базой было удобно базе, а общение с ОО миром оставалось ОО. Разумеется, все это за счет агрессивного и умного кеширования. У Вас другие предложения? Предложение выкинуть ОО на свалку, очевидно, встречает предложение выкинуть РСУБД на соседнюю. Конструктива на этом пути не получится. Так что - да здравствует эволюция ормов. Подозреваю, что и разработчики РСУБД, глядя на победное шествие ОО, пойдут навстречу ОРМам - оптимизировать некоторые "неудобные" сценарии, насколько возможно.

PS Про рефакторинг нашел кое-что сам. Любопытно. Небогато, но в мире без нормального ОО лучше вряд ли получится
http://www.toadworld.com/Default.asp...67&EntryID=321
http://www.toadworld.com/Default.asp...67&EntryID=328
http://www.toadworld.com/Default.asp...67&EntryID=346

[tpc]

Сообщение от svu

У Вас другие предложения? Предложение выкинуть ОО на свалку, очевидно, встречает предложение выкинуть РСУБД на соседнюю. Конструктива на этом пути не получится.

вроде уже свои предложения высказывал. выкидывать нужно орм, конструктивное предложение LINQ, SqalaQL.

Сообщение от svu

PS Про рефакторинг нашел кое-что сам. Любопытно. Небогато, но в мире без нормального ОО лучше вряд ли получится

ну аргументами, чего не хватает сможете пояснить ?

tpc добавил 03.05.2010 в 12:13

Сообщение от svu

Спасибо за ссылку, любопытные картинки - но они только подтверждают то, что я ожидал - в мире plsql не может быть юнит тестов. Точнее, теоретически может, но за юнит-тестируемый код отрывают гениталии, как Вы любезно нам сообщили (ибо они действительно идут в разрез с принятым стилем разработки plsql)

да, с точки зрения pl/sql чистые юнит тесты делать бред, но не вижу принципиальных проблем. вместо переписывания объектов доступа к бд в pl/sql можно заменить таблицы вьюшками одетыми на pl/sql таблицы, но в здравом уме как и в жава таким никто заниматься не станет.

[svu]

Сообщение от tpc

конструктивное предложение LINQ, SqalaQL.

Ни в коем случае. Нафиг. Это называется эклектика в ЯП. Если язык ОО - он должен оставаться ОО. Попытка зафигачить SQLоиды в ОО язык - это синтаксический бардак. Я очень рад, что жабка (пока что) не идет этим путем. Правда, тут оракл купил сан...

Не надо это все выносить на уровень языка - оставьте это все библиотекам. А в виде библиотек это те же ОРМы.

Сообщение от tpc

ну аргументами, чего не хватает сможете пояснить ?

На самом деле, то, чего не хватает - оно все из мира ОО (работа с классами, наследованием и пр.), поэтому я и сказал, что лучше вряд ли получится.

[tpc]

Сообщение от svu

Не надо это все выносить на уровень языка - оставьте это все библиотекам. А в виде библиотек это те же ОРМы.

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

Сообщение от svu

На самом деле, то, чего не хватает - оно все из мира ОО (работа с классами, наследованием и пр.), поэтому я и сказал, что лучше вряд ли получится.

ну извини, это тараканы именно ООП, к стате pl/sql уже часть этих тараканов благополучно пережил.
вот они, уже зажившие шрамы на теле пл-скл:
http://www.oracle.com/global/ru/oram...3/dev_aoo.html

[svu]

Сообщение от tpc

наконец пришло осознание, что проблема в консерватории

Честно говоря, я не очень понимаю, где тут консерватории и филармонии. От ОО никто не собирается отказываться, LINQ ничего принципиально нового по сравнению с тысячелетним ProC не дает. Это же все синтаксический сахар, бессмысленно портящий язык - а по сути тот же ОРМ (я, думаю, справлюсь написать Вам код на LINQ, который будет правильным ОО и будет "внизу" кошмарным сиквелем.

http://en.wikipedia.org/wiki/Languag...ry#LINQ_to_SQL - найдите 10 отличий от обычного жабского орма, если убрать синтаксический сахар.

Делая шаг назад. Есть мысль, что чем менее сиквельным будет ОО интерфейс, тем больше простор для "ума" (оптимизации) на уровне ОРМ. Это как с языками программирования и компиляторами (в сущности, это даже не аналогия, это частный случай). Чем высокоуровневей язык, тем больше простор для оптимизации в компиляторе. Поэтому правильно было бы в ОО языках использовать не подход "выдай мне конструкцию, наиболее близкую к окончательному сиквелю", а "скажи мне, чего ты НА САМОМ деле хочешь, я соптимизирую это так, чтобы базе было удобно с тобой работать". Причем конкретной базе, можно тюнить оптимизацию под вендора, под версию...

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

Сообщение от tpc

вот они, уже зажившие шрамы на теле пл-скл:

Да, жестко. Мы тоже таким баловались в 2000г (не прямо таким, а пытались писать в ОО стиле на plsql - выглядело сурово)

[tpc]

Сообщение от svu

От ОО никто не собирается отказываться, LINQ ничего принципиально нового по сравнению с тысячелетним ProC не дает. Это же все синтаксический сахар, бессмысленно портящий язык - а по сути тот же ОРМ

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

var q = animals
  .Where(a => a.CanFly)
  .Select(a => new { a.Id, a.Name })
  .OrderByDescending(a => a.Id);

поверьте, это очень отличается от всего того, что было в императивном ООП до сих пор.

[svu]

Сообщение от tpc

поверьте, это очень отличается от всего того, что было в императивном ООП до сих пор.

Правда чоль??? Я, наверное, не очень понимаю, что для Вас есть "императивное ООП". animals так или иначе - список объектов. Модный хибернейт делает примерно ту же фигню: http://docs.jboss.org/hibernate/core.../queryhql.html
Я же говорю - разница между LINQ и современными ОРМами только в синтаксе, по большому счету. Точнее, LINQ является (ИМХО ужасной по определению) попыткой сделать ОРМ в базовом ОО языке, вместо библиотеки.

[Kot]

Сообщение от tpc

я не говорю что ооп плохо, я утверждаю, что мыслящий объектами жава девелопер создает проблемы рсубд неестественной для рсубд нагрузкой (обычно это запросы в цикле)

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

Еще раз: я правда не могу понять ваши аргументы почему ОРМ создает проблемы...

Сообщение от tpc

вы начинаете гнуть пальцы не понимая, о чем говорит опонент

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

[AlexL]

весь спор крутится вокруг навязанных svu трех причин:

1. архитектурная правильность
2. оо девелоперы не должны разбираться в sql коде
3. портируемость приложений

выскажу свое мнение, так как я более 10 лет разрабатывал оо приложения:

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

2. проблема оо девелоперов, каждый уважающий себя оо девелопер обязан знать основы СУБД.
3. возникают из-за проблем с архитектурой, неправильным выбором технологий, средств разработки и средств хранения данных.