Porządkowanie po sequence number

Chyba o coś takiego chodziło, muszę jeszcze przetrawic tą linie:

min(case when seq_no<20000 then 999999 else seq_no end)

jakby sie zdarzyło że rekordu 999999 nie ma, i po 999998 jest 000001

Dzięki!!

Psie Sabo, nie idź ta drogą.

Do BŁĘDNEJ struktury tabeli, dokładacie złożoność kwadratową, czy sześcienną, bez indeksów itd... już dawno zabłądziliście w lesie i poruszacie się pogarszając sytuację.
Proponuję dobrze przestudiować bajkę "król jest nagi"

Postudiować ELEMENTARZ a nie programować produkcję

Panczo napisał(a):

Ja tu czegoś nie rozumiem, piszesz o tabeli na 10000 rekordów, to nie jest jakoś specjalnie dużo, nawet dla wersji express. Czy obawa przed wydłużeniem czasu zapisu nie jest zbyt na wyrost?

....

Ty ten najstarszy numer potrzebujesz w jakim celu?

Jeśli się błędnie powiedziało A, to nadal się brnie w tym samym kierunku, mówiąc B,C
Ot, całą tajemnica wątku.

Teraz dopiero zobaczyłem rozwiazanie @Marcin.Miga i ono jest bardzie przejrzyste i nie ma rozkminy w momencie braku ostatniego numeru, a raczej jego braku:

select top 1
   seq_no
from (select 
               cast(substring(seq,11,6) as int) seq_no 
          from tb) t
order by 
    sign(500000-seq_no)
    ,seq_no

@AnyKtokolwiek ja rozumiem, że masz misję ewangelizacji w zakresie dobrze zaprojektowanych baz, ale sposób w ktory to robisz nie jest chyba najlepszą drogą:
zarzucasz OP że nie ma PK nie mając informacji o tym jak tabela wygląda (nie został pokazany nigdzie DDL), informacje o tym, że OP nie ma wpływu na strukture, zbywasz tym, że jednak ma.

Aby było jasne, też uważam, że to nie jest dobrze zaprojektowane, ale w długoletniej praktyce zdarzalo mi się rzeźbić w gównie, tylko dlatego, że nie miałem wpływu na strukturę i musiałem sie opierać na tym co mam. Poza tym prezentujesz w tonach swoich wypowiedzi wyższość nad pytającym, a to z założenia się nie sprawdza w relacji uczeń - nauczyciel i osobiście bardzo tego nie lubię.

Dziękuje wszytskim odpowiedzi. Jak widze jest wiele rozwiązań. Spodobało mi sie to ostatnie, bardzo praktyczne i proste :)

Chciałbym tu jeszcze poruszyc problem przedstawiony przez @AnyKtokolwiek. Już nie chodzi o pokazanie jak taka baza powinna wyglądać. Jakie są wady nieideksowanej bazy danych, jednotabelowej, zaiwerającej 10000 string(200), w kontekście niezawodności. Przeszukałem googla i jedyna wadą jest wolniejszy dostęp w wyszukiwaniu danych, za to szybsza w dodawaniu rekordów. Rozumie niechęć niektórych do odpowiedzi, wiedza kosztuje, czas to pieniądz, itp. Nie ukrywam że przyszedłem na to forum, żeby się czegoś nauczyć, od tych co siedzą na codzień w bazach. Ja wtym nie siedzę i nie będę siedział, zaawansowana wiedza nie jest mi potrzebana, ale pomimo wieku dawno poststudenckiego lubie się uczyć :)

@Usjwo w kwesti niezawodności nie ma żadnych. Zwroć proszę tylko uwage na kontekst w którym sie wypowiadasz. 10000 rekordów w tabeli z kolumną varchar(200) to jest 2 MB danych. O jakich optymalizacjach zapisu ty piszesz? Tego "zysku z zapisu" nie będziesz w stanie policzyć...

Ja zakladam, że te pozostałe 196 znaków słuzy Ci do jakichś zadań, niezaleznie od postaci danych jakie przyjmiesz, zgodnie ze sztuką nalezaloby je rozbić na wartości skalarne, niż bawić się substringami, zarówno po stronie zapytań jak i aplikacji. Bo teeraz czuje się jakbym wrócil do lat 90. i bawil sie DBF-ami ;)

Panczo napisał(a):

@Usjwo w kwesti niezawodności nie ma żadnych. Zwroć proszę tylko uwage na kontekst w którym sie wypowiadasz. 10000 rekordów w tabeli z kolumną varchar(200) to jest 2 MB danych. O jakich optymalizacjach zapisu ty piszesz? Tego "zysku z zapisu" nie będziesz w stanie policzyć...

Dla mnie to nie ma zadnego znaczenia, to w internetach zyski i straty.

Panczo napisał(a):

Ja zakladam, że te pozostałe 196 znaków słuzy Ci do jakichś zadań, niezaleznie od postaci danych jakie przyjmiesz, zgodnie ze sztuką nalezaloby je rozbić na wartości skalarne, niż bawić się substringami, zarówno po stronie zapytań jak i aplikacji. Bo teeraz czuje się jakbym wrócil do lat 90. i bawil sie DBF-ami ;)

Do niczego mi nie służy, ja przekazuje je dalej. Patrzysz z punktu widzenia bazodanowca. Tu baza danych jest tylko bufforem.
Czasami nie ma sequence number, czasami jest w innym miejscu, nie zawsze jest to numer. Przy takiej strukturze, w zależności od wersji zmieniam tylko SELECTA dla pobrania danych (co bylo przyczyną tego wątka). Reszta applicacji i struktura bazy danych zostaje taka sama. Można z armaty strzelać do komara, kto bogatemu zabroni. Żeby zmenić strukture bazy, musiałbym widzieć jakiś zysk, niezawodność lub oszczędność czasu (mojego, nie dostępu do bazy ;) ). Jak na razie tego nie widzę, a wprost przeciwnie.