Здравствуйте, vvaizh, Вы писали:
V>Поэтому нужно именно то что я написал.. V>Это только он в своём примере написал что у него id по порядку идут, в реальности это не так!
Так речь-то именно о его примере! В том-то и вопрос. А ты начинаешь "принимать по умолчанию" ряд условий, которых изначально не было. Если база данных динамически обновляется, то всяко может быть в принципе. Даже запрос типа:
SELECT * FROM fucking_table WHERE Id > 4 LIMIT 1
Может жахнуть по причине отсуствия таковых полей (соответственно по причине их удаления). Дык по Ид в таком случае вообще уже нельзя. Т.е. суть в чем: если я знаю, какие поля точно есть, тогда можно без лимита; если я вообще это не знаю, тогда бредово в принципе использовать статические значения полей в каком бы то ни было виде. А если знаю, что поле Ид 5 точно есть, то следующие запросы будут идентичны:
ВВ>Так речь-то именно о его примере! В том-то и вопрос. А ты начинаешь "принимать по умолчанию" ряд условий, которых изначально не было. Если база данных динамически обновляется, то всяко может быть в принципе. Даже запрос типа:
Совершенно верно, я исхожу из своего опыта, и как вижу из отзывов "попал в точку.."
Так как это очень распространённая задача (в каком то виде она как правило решается ___везде___)
Любая табличка, отображающая базу данных должны уметь это делать..
Любая форма-страница с возможностью навигации..
Я даже не знаю обратных примеров..
ВВ>Может жахнуть по причине отсуствия таковых полей (соответственно по причине их удаления). Дык по Ид в таком случае вообще уже нельзя.
Выкинуть колонку ID может по правильному только администратор базы данных, который в этом случае несёт также ответственность и за все запросы, которые он должен переписать...
Удалить же запись с id=5 может как правило пользователь!
И все запросыы при этом должны продолжать работать (т.е. по правильному пльзователь не может повалить базу..)
Здравствуйте, vvaizh, Вы писали:
V>Выкинуть колонку ID может по правильному только администратор базы данных, который в этом случае несёт также ответственность и за все запросы, которые он должен переписать... V>Удалить же запись с id=5 может как правило пользователь! V>И все запросыы при этом должны продолжать работать (т.е. по правильному пльзователь не может повалить базу..)
Ты немного не понял. речь не о том, что выкинуть всю колонку, а том, чтобы удалить ряд записей. Если есть 10 записей, то при этом пользователь удаляет все записи от 5, вот тогда и будет. Конечно бороться с этим можно, но сам подход для последовательной выборки довольно странный.
В общем я к тому, что последовательная выборка всегда осуществляется средствами ридера. В АДО — это метод Read и пр.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, vvaizh, Вы писали:
V>Выкинуть колонку ID может по правильному только администратор базы данных, который в этом случае несёт также ответственность и за все запросы, которые он должен переписать... V>Удалить же запись с id=5 может как правило пользователь! V>И все запросыы при этом должны продолжать работать (т.е. по правильному пльзователь не может повалить базу..)
ВВ>Ты немного не понял. речь не о том, что выкинуть всю колонку, а том, чтобы удалить ряд записей. Если есть 10 записей, то при этом пользователь удаляет все записи от 5, вот тогда и будет.
Запрос сработает и в этом случае, он вернёт пустую выборку..
Тут всё дело в блокировках, если в ВЕБ-приложениях позволять каждому юзеру что то блокировать на сервере в течении сессии, то это плохо кончится, поэтому так не делают..
ВВ>Конечно бороться с этим можно, но сам подход для последовательной выборки довольно странный. ВВ>В общем я к тому, что последовательная выборка всегда осуществляется средствами ридера. В АДО — это метод Read и пр.
Ну а они то по итогу как по твоему работают?
Всё равно через SQL!
для T-SQL это keyword TOP!
Тут ещё предлагалось использовать cursor-ы
(которые возможно использовать и для твоего Read)
Но, во первых на mySQL нет курсоров, а во вторых они предполагают затраты ресурсов на стороне сервера в течении всего существования сессии, что для WEB-приложния плохо (с течением времени это сильно замедляет скорость работы сервера), так что тут лучше обойтись простым запросом — сделал, забыл (в сессии на стороне сервера ничего хранить не нужноюю)
Здравствуйте, vvaizh, Вы писали:
V>Тут ещё предлагалось использовать cursor-ы V>(которые возможно использовать и для твоего Read) V>Но, во первых на mySQL нет курсоров, а во вторых они предполагают затраты ресурсов на стороне сервера в течении всего существования сессии, что для WEB-приложния плохо (с течением времени это сильно замедляет скорость работы сервера), так что тут лучше обойтись простым запросом — сделал, забыл (в сессии на стороне сервера ничего хранить не нужноюю)
Кстати, это уже интересный вопрос. Что собственно лучше. лучше ли использовать один раз дебильный запрос вроде SELECT * FROM fucking_table, а затем продвигаться по записям ридером. Или же для передвижения по записям использовать каждый раз новый запрос.
ВВ>Кстати, это уже интересный вопрос. Что собственно лучше. лучше ли использовать один раз дебильный запрос вроде SELECT * FROM fucking_table, а затем продвигаться по записям ридером.
Ещё раз напоминаю, речь идёт о веб приложении...
в этом случае, вы свой риадер должны будете завобдить в сессии..
т.е. зашло 1000 пользователей..
на каждый система завела по ридеру..
пользователи пошли курить..
ридеры будут торчать ещё несколько минут..
В моём случае, сервер может использовать вообще 1 коннектион на всех пользователей, и соотв.
Возможности масштабирования гораздо богаче ..
Что нагладно демонстрирует Google..
Если бьы он заводил reader на каждого кто ищет, и держал бы его пока человеку не надоест (и ещё несколько минут после этого) ТАКОЙ скорости мы не увидали бы..
ВВ>Или же для передвижения по записям использовать каждый раз новый запрос.
Ещё раз повторяю, это — сложившаяся общепринятая практика для ___WEB___приложений..!
Здравствуйте, vvaizh, Вы писали:
ВВ>>Или же для передвижения по записям использовать каждый раз новый запрос. V>Ещё раз повторяю, это — сложившаяся общепринятая практика для ___WEB___приложений..!
Я не спорю, что сложившаяся. Сам я никогда такой выборки, какую автор первого поста описал, в веб не делал, не приходилось как-то.
Вопрос был собственно общий. Не как это для веба, а как это вообще. В плане оптимизации разумеется. В смысле your opinion.
