вадя,

а вот с этим как ?

вадя,

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

Да!!!! ))

Он же о чём говорит в это видео ?
О том, что очень сложно поддерживать бизнес логику, реализованную на стороне SQL сервера в виде хранимых процедур.

Если я понял правильно)

вадя,

авторwebsocket . это вместо ajax. это прелесть ...

Попробую на вкус) Спасибо)

Petro123,

авторЛень? Не способен? Тогда углубляй только sql и не флуди).

И не лень) И способен) Просто уточняю. Да и не флудим.

вадяZenia,
50 таблиц это не много, и можно обойтись одним jdbc.
вопрос не в количестве таблиц , а грамотности составления структуры базы.
чем грамотнее подход к данным - тем проще связи, проще для восприятия.
спроси у аксессников - по сколько у них таблиц, и обходится всё без прокладок. а уж задачи решаются по-серьёзнее чем на java (с точки зрения обработки данных).
аксес чем хорошо - позволяет разграничить две области обрабока данных и отображение результатов.
явисты же всё это смешивают в одну корзину.
в mssql измеряют запросы/хранимки не строками , а экранами кода. никакая прокладка не сможет обеспечить создание такой логики. и получение результата будет намного быстрее с использованием обработки на java


вадя,

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

Ни в коем случае не спорю)

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

Также сказано, что DOM модель строиться по её правилам, а структура таблиц - по своим правилам.
Конечно потом надо всё шлифовать в процессе)

Скорее всего этим подходам можно доверять. Наверное ORM технологии позволяют справляться со сложностью проектов.
Позволяют работать в терминах объектов (DOM). Вместе с распределёнными транзакциями в том числе.

Вадя, есть ощущение, что ORM эффективнее для реализации сложной бизнес-логики (где скорость не так важна).
Есть ощущение, что ORM убирает рутину также)

Локшин МаркNeboГоворится также, что размещать бизнес логику на сторону SQL сервера в виде запросов, хранимых процедур - это неправильно! Что там должны лежать только чистые данные.

Старые и избитые песни людей, не осиливших SQL и изобретающих свои велосипеды на типичные задачи на которые заточены современные СУБД.


))) мне кажется SQL проще осилить, чем ORM

вадя,

автор+100500
и намного полезней

Может быть) Проверим)