jit>Пишем большое "базо-независимое" приложение, те. которое работает и на MS SQL, и на MySQL, и даже на MS Access.

большое базо-ненавистническое приложение, которое одинаково неэффективно работает с любой БД...

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

jit>

jit>SELECT *
jit>FROM Users
jit>WHERE UserID > (MAX(UserID)-10)
jit>

jit>Где UserID — первичный ключ. Как вам такой способ?

А кто гарантирует что в первичный ключе не будет пропусков между значениями?

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


jit>

jit>SELECT *
jit>FROM Users
jit>WHERE UserID > (MAX(UserID)-10)
jit>

jit>Где UserID — первичный ключ. Как вам такой способ? Может еще идеи есть?


твой запрос работать не будет — у тебя аггрегатная функция неправильно используется
можно так переписать:

SELECT *
FROM Users
WHERE UserID > (SELECT max(UserID) — 10 from Users)

но этоне будет работать если в UserID есть пробелы (1,2,5,7,...)

а классическое рещение выглядит так:

SELECT *
FROM Users T1
WHERE 10 > (SELECT COUNT(1)
FROM Users T2
WHERE T1.UserID < T2.UserID)

и оно должно работать в ansi sql.

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

jit>Пишем большое "базо-независимое" приложение, те. которое работает и на MS SQL, и на MySQL, и даже на MS Access.

jit>По ходу дела естественно сталкивались с ОГРОМНЫМ количеством нюансов (например драйвер mySQL и MS SQL по разному маршалят тип bool и тд. и тп.)

jit>Сейчас столкнулись с очередным багом — синтаксис вот такого запроса — "SELECT TOP 10" — везде разный. В Оракле один (ROWCOUNT), в Мускуле другой (LIMIT 10), в MS SQL третий (TOP 10). .. Как бы так извратиться, чтобы написать эту вещь универсально?

jit>Пока дошли только до такого изврата:

jit>

jit>SELECT *
jit>FROM Users
jit>WHERE UserID > (MAX(UserID)-10)
jit>

jit>Где UserID — первичный ключ. Как вам такой способ? Может еще идеи есть?

1) Надо знать все диалекты...
2) Использовать ORM который умеет работать со всеми вашими СУБД... (если такой существует)
3) Писать хранимые процедуры типа GETSOMETOPROWS(@table_name, @count) и создавать их во время разворачивания окружения (environment) приложения.

jit пишет:
> Сейчас столкнулись с очередным багом — синтаксис вот такого запроса —
> "SELECT TOP 10" — везде разный. В Оракле один (ROWCOUNT), в Мускуле
> другой (LIMIT 10), в MS SQL третий (TOP 10). .. Как бы так извратиться,
> чтобы написать эту вещь универсально?

На SQL вы этого универсально не сделаете.

Но решение просто — вы посылаете с клиента запрос,
выбираете 10 записей, и отказываетесь от дальнейшей работы
с данными. (SQLCancel()) . Это работает везде и даже по
производительности будет не сильно хуже.
(единственный минус — оптимизатор не будет знать, что вам
надо только 10 первых строк, но применить это можно
тоже не всегда).

Пишем большое "базо-независимое" приложение, те. которое работает и на MS SQL, и на MySQL, и даже на MS Access.

По ходу дела естественно сталкивались с ОГРОМНЫМ количеством нюансов (например драйвер mySQL и MS SQL по разному маршалят тип bool и тд. и тп.)

Сейчас столкнулись с очередным багом — синтаксис вот такого запроса — "SELECT TOP 10" — везде разный. В Оракле один (ROWCOUNT), в Мускуле другой (LIMIT 10), в MS SQL третий (TOP 10). .. Как бы так извратиться, чтобы написать эту вещь универсально?

Пока дошли только до такого изврата:

SELECT *
FROM Users
WHERE UserID > (MAX(UserID)-10)

Где UserID — первичный ключ. Как вам такой способ? Может еще идеи есть?

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

jit>>

jit>>SELECT *
jit>>FROM Users
jit>>WHERE UserID > (MAX(UserID)-10)
jit>>

jit>>Где UserID — первичный ключ. Как вам такой способ?
AJD>А кто гарантирует что в первичный ключе не будет пропусков между значениями?

А кто гарантирует что UserId это ваще число или строка?

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

_>твой запрос работать не будет — у тебя аггрегатная функция неправильно используется

Если сменить where на having — будет Спешил просто.

_>но этоне будет работать если в UserID есть пробелы (1,2,5,7,...)

У нас не критичный случай. Плюс-минус километр Надо вывести "несколько" последних записей из журнала событий.

_>а классическое рещение выглядит так:

спасибо

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

jit>Если сменить where на having — будет Спешил просто.

не будет. да и group by нету


_>>а классическое рещение выглядит так:

jit>спасибо

да, я забыл написать, что на больших таблицах это будет долго работать