_usa__83_,

В тоже время таскать за раз из базы больше 50-100 записей вроде как и не очень разумно, а вот иметь доступ к записям если "основного" представления это не очень накладно вроде как и не очень плохо. Хотя ...
кто тебе сказал, что не разумно????
базы они для того и предназначены чтоб выдавать данные какие нужны, а не все.
можно по пальцам пересчитать когда юзеру нужно просматривать 1к записей, и это только если просто просмотреть....
максимум- 2 экрана, если вывод больше - не правильный фильтр для выбора. и фильр надо делать именно в запросе, а не на клиенте фильтровать из мильона записей.
для базы менее накладно выбрать n-раз из мильна записе 50 и их отправить клиенту, чем выбрать все и отправить.

mad_nazgul,
хорошее знание sql позволяет очень много реализовать именно на sql, что обеспечит и скорость и простоту кода.

Blazkowiczвадяmad_nazgul,
хорошее знание sql позволяет очень много реализовать именно на sql, что обеспечит и скорость и простоту кода.
Простоту кода? Когда у тебя по десятку JOIN-ов на запрос? Не смеши.
не надо утрировать, десяток джойнов это не много,
если для тебя это много, значит ты не очень хорошо разбираешся в базах. количество джойнов не является определением сложности.

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

авторУже сам забыл какую херню написал про "простоту кода"? ORM как раз позволяет избегать однотипных запросов с массой JOIN-ов. Когда у тебя в системе пачки жирных SQL ни о какой "простоте" речи быть не может
если для тебя написание хорошего запроса является сложностью - это твоя проблема.
однотипные запросы это не проблема и этого пугаться не стоит.
c помощью ORM невоможно построить наиболее быструю систему, ни одна прослойка не сможет заменить голову программмиста, владеющего нормальными знаниями sql, ни одна прослойка не сможет воспользоваться всеми возможностями каждой субд.
все эти прослойки используют лишь минимальную часть возможностей субд.
ни одна прослойка не сможет использовать (в применении к mysql) операторы case, concat, concat_ws, group_cocat и куча прочих.
по сути прослойка - это только джойны.
я для этих целей использую знания и специализированный инструмент, поэтому сделать запрос из любого количества таблиц и джойнов не проблема, помимо этого есть и подзапросы и функции и представления. которые позволяют многое,
это то, что ориентированно именно на работу с большим объёмом данных.
это то что позволяет выдать в код java наиболее быстрым образом наиболее подготовленные для дальнейшей обработки и отображения данные. по факту уже готовые для отображения.
и поверь , что алгоритмы и методы баз работают намного быстее , чем код на java.
авторКто с этим спорит? Я точно так же знаю десятки примеров, когда построение системы начинают с GUI. Выходит Delphi - говно.
это не значит, что эти примеры - правильное построение систем.

авторНаписание вообще ни для кого не является сложность. Наколбасить любой может мама не горюй. Проблема потом в том чтобы в эту колбасу вносить исправления.
если написанное тобой - наколбашено - то да,
в хорошо постоенную систему можно без проблем вносить изменения.
разбираться в чужом sql - ещё проже , чем в коде java.
да и счас есть куча инструментов позволяющих намного упростить данное действо.
если ты по-старинке пишешь sql запросы в блокноте, то да , но это твои проблемы.
я пользуюсь DbForge, и хранимки и запросы строю в гуи, и мне нет проблем разбираться практически в любой сложности запроса.

авторСколько раз нужно повторять что производительность пофигу. Масштабируемость важнее.
ну вот и получаем кучу томознутых систем.

авторЛюбые SQL функции в Hibernate уже работают лет 10.
ты путаешь мух с котлетами, о чем тебе и сказал mad_nazgul
то что там много что работает, это не значит, что это создано прослойкой, это написано программистом,
в итоге получается -написать запрос для прослойки, потом прослойку заставить делать ещё что-то...
потом ещё и разбираться, что сотворила эта прослойка...
вместо того чтоб написать сразу необходимое.
авторНо следуя твоей логике Delphi всё равно говно потому что не запрещает так писать. "Ведь нормальную голову программиста никаким (подставь любой термин) не заменить." Вот и вся твоя аргументация.
написать гавнокод можно на любом ЯП, но это не означает , что этот ЯП гавно.


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

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

maytonBlazkowiczВ другом проекте как-то делал очень клевый фильтр. Работает как поиск в Windows 10. Просто набираешь текст, а фильтр, обновляет таблицу, добавля like критерий к запросу.
А я щас разгребаю последствия такого одного "клёвого фильтра". Много like-ов по многим полям... Full-table-scan...

Денормализую. Добавляю CONTEXT-индекс.
я тоже делаю такие фильты, но только всё работет без проблем .
и многое зависит от использования конкретной субд.
к примеру mysql 5.7.ХХ уже использует для такого рода поиска индексы. без денормализации.
к примеру в таблице с 10 лямами строк - полный поиск (заранее не существующей записи, т.е. перебор всех строк) - 4 сек
практически у меня не было необходимости производить поиск в таком объёме. несколько сотен тысяч - реальный объём, - поиск многовенный

BlazkowiczВ другом проекте как-то делал очень клевый фильтр. Работает как поиск в Windows 10. Просто набираешь текст, а фильтр, обновляет таблицу, добавля like критерий к запросу.
такой фильтр я начал использовать в конце 90-х....

maytonЯ почти не работал с mysql и не знаю как там устроен индексный поиск. Но в большинстве dbms
если мы указываем attribute like '%'+search_expression+'%' то оптимизатор выбирает FTS.

я не даром указал версию mysql, в нижних версиях аналогичный поиск происходил 30 сек.



maytonИ кстати... 4 секунды - это достаточно долго. Помним маркетинговое правило 3х секунд.
Клиент уходит не дождавшись на другую вкладку.
но в таком поиске не переход на страницу :)
и это время 10 000 000 строк, повторюсь, реальная задача поиск в наборе товаров, поставщиков.. а это максимум десятки-сотни тысяч.

maytonДля корпоративных систем возможно 4 сек это и нормально но если подумать о постоянной
нагрузке - то дело плохо. Нельзя FTS-ить одну таблицу постоянно. Должны быть паузы в нагрузке.
согласен, но в используемых с этим поиском базах (access, mssql, mysql) это не сказывалось особо на нагрузке...
зато позволяло организовать работу операторов настолько быстрой и удобной, что они могли подготовить к передаче по факсу счёт во время телефонного заказа клиента с учетом возможных замен, остатков, резервов и поступлений.

mayton,
PS
веб-проекте такой поиск по вводу очередного символа, в наборе из 28000 наименований, в пути браузер-сервер-приложение-база-приложение-сервер-браузер - задержки не ощущается.