SQL: Laatste 5 entries van een tabel

[Verwijderd]

Beste Tweakers,

Ik zit met een probleem en weet niet precies hoe deze simpel op te lossen, vandaar deze topic.
Ik wil d.m.v. een sql querie de laatste 5 ingevoerde rijen van een table ophalen. Let op, deze tabel heeft geen primary key, dus sorteren en daarvan de 5 laaste tupels eruithalen zou niet correct zijn.
Deze tabel heeft GEEN attribut waardoor ik entry tijd zou kunnen bepalen.

Iemand een idee?

p.s. Ik wil graag mijn database houden zoals hij is, dus geen nieuwe tabellen ofzo invoegen.

Alvast bedankt.

Greetings,
Irfaan

[d00d]

Ik weet niet welke database je gebruikt, maar in het geval van SQL Server is dit niet mogelijk...

[eek]

Waarom heb je geen primary key in je tabel?
Heb je geen ander veld waar je op kan sorteren?
Als je niets wilt aanpassen in je tabel (bijv. nieuw "INSERT_DATE" veld) dan gaat dat sowieso niet lukken.

[Verwijderd]

Postgresql.

Dat is de database server die ik gebruik.

[Verwijderd]

Hmmm,

Dan maar zo:

Ik kan natuurlijk een extra tabel maken met een primary key en daarin de "nieuwste" ingevoerde tupel van mijn tabel koppelen.
Daarna deze sorteren en uitlezen.

Iemand een idee hoe ik de 5 laaste entries van een gesorteerde tabel eruit haalt?

Txns,
Irfaan

[eek]

Omgekeerd sorteren en dan de eerst 5 pakken.

Waarom wil je het trouwens zo vreemd oplossen?

[ Voor 36% gewijzigd door eek op 03-07-2007 14:00 ]

[d00d]

Verwijderd schreef op dinsdag 03 juli 2007 @ 13:55:
Postgresql.

Dat is de database server die ik gebruik.

Ja, dat verandert de zaak, volgens mij heeft iedere tabel heeft een OID (object identifier) waar je deze informatie uit kunt halen.

[TeeDee]

p.s. Ik wil graag mijn database houden zoals hij is, dus geen nieuwe tabellen ofzo invoegen.

Als je dan toch gaat klussen, pas dan je datamodel aan zodat het wel fatsoenlijk is. Nu weet ik verder niet hoe het model eruitziet...

d00d schreef op dinsdag 03 juli 2007 @ 14:00:
[...]
Ja, dat verandert de zaak, volgens mij heeft iedere tabel heeft een OID (object identifier) waar je deze informatie uit kunt halen.

Kan ook

[ Voor 40% gewijzigd door TeeDee op 03-07-2007 14:02 ]

[Verwijderd]

[/quote]
Omgekeerd sorteren en dan de eerst 5 pakken.
[quote]

De eerste 5 pakken? Een voorbeeld hoe je dat zou kunnen doen?

txns

[ Voor 24% gewijzigd door Verwijderd op 03-07-2007 14:08 ]

[Verwijderd]

definieer de "Laatste" als jou database geen primary key heeft ( hoogst onwaarschijnlijk ).

Hoe selecteer jij unieke records?

[eek]

Door op google te zoeken op postgres en limit

[Verwijderd]

Kijk, that´s more like it.

Ik weet dat ik niet zomaar gekozen had voor Postgresql boven Mysql so you can see:
Postgresql IS the most advanced OpenSource DBMS!

Bedankt allemaal.

[killercow]

Verwijderd schreef op dinsdag 03 juli 2007 @ 14:13:
Kijk, that´s more like it.

Ik weet dat ik niet zomaar gekozen had voor Postgresql boven Mysql so you can see:
Postgresql IS the most advanced OpenSource DBMS!

Bedankt allemaal.

Sorry hoor,

Je bent ook eerst formule 1 gaan rijden? of heb je gewoon een VW golfje?
Volgens mij maakt het geen fuck uit welke DB jij gebruikt, met je huidige kennis niveau misbruik je ze imho toch allemaal.

Zoek eerst een tutorial sql op, en een tutorial database normalisatie, dan kun je de gereedschappen die je zo graag gebruiken wilt ook echt hanteren.

[eek]

Psssst....

[Hydra]

Verwijderd schreef op dinsdag 03 juli 2007 @ 14:13:
Kijk, that´s more like it.

Ik weet dat ik niet zomaar gekozen had voor Postgresql boven Mysql so you can see:
Postgresql IS the most advanced OpenSource DBMS!

Bedankt allemaal.

Alsof andere systemen geen 'LIMIT' functionaliteit hebben

[sig69]

Verwijderd schreef op dinsdag 03 juli 2007 @ 14:09:
definieer de "Laatste" als jou database geen primary key heeft ( hoogst onwaarschijnlijk ).

Hoe selecteer jij unieke records?

Sorteren op PK hoeft ook niet goed te gaan, je PK kan net zo goed een string of Guid of whatever zijn. Voor zoiets zou ik een timestamp gebruiken, of op z'n minst gewoon een int.

[Verwijderd]

Hydra schreef op woensdag 04 juli 2007 @ 11:30:
[...]


Alsof andere systemen geen 'LIMIT' functionaliteit hebben

Idd, lol Keek ook even raar toen ik het las...

Maar denk ik nou te simpel als ik denk:

"SELECT * FROM TABLE OFFSET(<COUNT> - 5)" (<COUNT> even opvragen met subquery oid)

[Varienaja]

Verwijderd schreef op woensdag 04 juli 2007 @ 13:43:
Maar denk ik nou te simpel als ik denk:

"SELECT * FROM TABLE OFFSET(<COUNT> - 5)" (<COUNT> even opvragen met subquery oid)

Selecties geven je een verzameling. Een kenmerk daarvan is dat de volgorde niet gedefinieerd is. Alleen als je een order by gebruikt kan je er vanuit gaan dat je resultaat geordend is.

Als ik een tabel met primary key genoeg bewerk door te inserten, deleten en opnieuw te inserten, en ik doe een select * from tabel, dan heb ik al vaak genoeg gezien dat de volgorde van de primary key niet meer wordt aangehouden.

De laatste 5 records in een tabel, zonder een kolom waarop je kunt sorteren is dus praktisch gezien onmogelijk. (Tenzij je terugvalt op de OID, de rownum, of wat dan ook)

[ACM]

d00d schreef op dinsdag 03 juli 2007 @ 14:00:
Ja, dat verandert de zaak, volgens mij heeft iedere tabel heeft een OID (object identifier) waar je deze informatie uit kunt halen.

Van die pagina:

OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled.

Het standaard toevoegen van OIDs is een tijdje geleden uitgezet (met 8.0 of 8.1) en de kans is dus vrij groot dat die niet bruikbaar zijn.

Hydra schreef op woensdag 04 juli 2007 @ 11:30:
Alsof andere systemen geen 'LIMIT' functionaliteit hebben

Nou... MySQL heeft het inderdaad ook, maar de anderen zijn wat lastiger hierbij hoor...

Verwijderd schreef op woensdag 04 juli 2007 @ 13:43:
Maar denk ik nou te simpel als ik denk:

"SELECT * FROM TABLE OFFSET(<COUNT> - 5)" (<COUNT> even opvragen met subquery oid)

Sja, eigenlijk wel. Want zoals gezegd is de volgorde op geen enkele manier gegarandeerd. MySQL sorteert het bijvoorbeeld vaak op de primary key (wat dus ook alfabetisch kan betekenen), postgres op de volgorde waarin ie ze binnenkrijgt (en een geupdate record staat dan meestal later in de lijst), etc. Het mooiste blijft het om op een of ander continu-oplopend veld van je tabel te sorteren. En dat kan dan zowel een sequence/serial/generator/autoincrement zijn als een datumveld.

[siepeltjuh]

Verwijderd schreef op dinsdag 03 juli 2007 @ 13:58:
Hmmm,

Dan maar zo:

Ik kan natuurlijk een extra tabel maken met een primary key en daarin de "nieuwste" ingevoerde tupel van mijn tabel koppelen.
Daarna deze sorteren en uitlezen.

Iemand een idee hoe ik de 5 laaste entries van een gesorteerde tabel eruit haalt?

Txns,
Irfaan

Maar sl je toch een relatie legt tussen 2 tabellen.? hoe wil je dan in godsnaam die relatie in stand houden als je geen uniek veld hebt of geen PK of uberhaupt iets dat te sorteren is op insert moment?

Nee nix geen tabellen aanmaken. Je moet gewoon een veld aanmaken met darin de insert timestamp of een fatsoenlijke PK.

[rrrandy]

Database tabellen zijn per definitie ongesorteerd, vergelijk ze met sets in bijv. Java. Wat jij wilt kan dus simpelweg niet!

[tss68nl]

God sta ons bij dat die gast niet bij de belastingdienst werkt om een productje te maken ofzo

[Mastermind]

Mijn hemel wat een crap inderdaad.

[b]iarsantoe schreef op dinsdag 03 juli 2007 @ 13:49[/b]:
p.s. Ik wil graag mijn database houden zoals hij is, dus geen nieuwe tabellen ofzo invoegen.

Voor welk bedrijf werk je kan ik alvast daar geen klant van worden

[ Voor 80% gewijzigd door Mastermind op 06-07-2007 02:30 ]

[aex351]

Verwijderd schreef op dinsdag 03 juli 2007 @ 13:49:
p.s. Ik wil graag mijn database houden zoals hij is, dus geen nieuwe tabellen ofzo invoegen.

Je geeft hiermee aan dat er dus ook geen data meer aan de db zal worden toegevoegd, gewijzigd of verwijderd.

Verwijderd schreef op dinsdag 03 juli 2007 @ 14:13:
Ik weet dat ik niet zomaar gekozen had voor Postgresql boven Mysql so you can see:
Postgresql IS the most advanced OpenSource DBMS!

Is dit grappig bedoeld ofzo? Want je laat duidelijk blijken dat je 0,0 verstand van SQL hebt, laat staan van een rdbms opzich.

tss68nl schreef op donderdag 05 juli 2007 @ 21:39:
God sta ons bij dat die gast niet bij de belastingdienst werkt om een productje te maken ofzo

-> Kortom je zal een tabel moeten wijzigen ->
Gewoon een extra veld toevoegen van type integer met eigenschap PK en automatisch oplopend. En probleem is opgelost.

[ Voor 57% gewijzigd door aex351 op 06-07-2007 05:11 ]

[g4wx3]

Ik weet niet hoe het zit met andere databases, maar ik denk dat MySQL veel beter is voor een beginner op DB-gebied (zoals ik).
Waarom?
Omdat je via PHPadmin allerlei opdrachten op je tabel kunt loslaten door simpel te klikken, deze opdrachten kun je zien, en kun je dan ook rechtsreeks in je php-bestand gebruiken.
Eigenlijk heb ik sinds dag 1 zo gewerkt, gewoon in MySQL kijken wat ik moet doen om bepaalde rijen te selecteren, en dan de opdracht doorlezen, en deze dan gebruiken als ondersteuning voor mijn php script.

[gorgi_19]

g4wx3 schreef op vrijdag 06 juli 2007 @ 08:02:
Ik weet niet hoe het zit met andere databases, maar ik denk dat MySQL veel beter is voor een beginner op DB-gebied (zoals ik).
Waarom?
Omdat je via PHPadmin allerlei opdrachten op je tabel kunt loslaten door simpel te klikken, deze opdrachten kun je zien, en kun je dan ook rechtsreeks in je php-bestand gebruiken.

Dat kan SQL Server (Enterprise Manager) ook. MS Access heeft hier ook een hele mooie interface voor.

[lier]

Ik ken Postgresql (praktisch gezien) helemaal niet, maar ondersteund deze ook triggers ?

Een nette oplossing (naar mijn bescheiden mening):

- voeg een veld toe aan de tabel waarin een timestamp van de insert (/update ?) komt.
- laat dit veld automatisch zetten door de trigger.

Dit heeft minimale consequenties voor je datamodel en levert wel de oplossing.

Offtopic: om wat voor applicatie gaat het (dat er een tabel bestaat waarop je een gesorteerde selectie wil doen, zonder dat deze een PK / FK / timestamp veld heeft ?

[ACM]

g4wx3 schreef op vrijdag 06 juli 2007 @ 08:02:
Ik weet niet hoe het zit met andere databases, maar ik denk dat MySQL veel beter is voor een beginner op DB-gebied (zoals ik).

Onzin, MySQL is wat dat betreft net als php. Makkelijk te leren, maar wel veel dingen op een niet-standaard of zelfs vieze manier. Bovendien moet je bij mysql rekening houden met zaken waar je bij andere databases niet op hoeft te letten en juist geen rekening met dingen waar je bij andere databases weer wel op moet letten. Maar voor je het vraagt, ik heb dit soort dingen af en toe meegemaakt maar het zijn vaak zulke obscure dingen dat ik ze ondertussen ook alweer vergeten ben
Maar o.a. de vieze ondersteuning voor datums zoals het feit dat 31 april een geldige datum is en gebrek aan fatsoenlijke interval-support (wat komt er uit date('5 april 2007') - date('3 april 2006') ?), het altijd opgeven van een default (als je not null zonder default kiest kan je toch het veld weglaten omdat er automatisch een default werd toegevoegd, bovendien is de default datum 0000-00-00 helemaal geen bestaande datum) en allerlei andere vage zaken met betrekking tot tabeldefinities.
Daarnaast is innodb's feedback over tabeldefinitiefouten ronduit dramatisch. Probeer maar eens een foreign key te verwijzen naar een niet-identiek datatype van een andere tabel (dus bijv smallint naar integer, waar op zich geen technisch bezwaar tegen is). Dan krijg je een of andere vage foutmelding waarvan je zelf moet uitvogelen wat ie mogelijk zou kunnen betekenen. Terwijl zoiets met name voor beginners niet erg duidelijk is.

Daarnaast heeft MySQL ondanks zijn hoge versienummer nog altijd de nodige bugs en/of worden er obscure nieuwe bugs geintroduceerd. Een paar weken terug had ik een query waar resultaat uit had moeten komen, in diverse herschreven vormen werkte ie wel, maar de meest efficiente niet... Dat was in MySQL 5.0.41, toen ik de query op dezelfde data in 5.0.38 testte werkte ie wel...
Overigens zijn het soort queries waar ik daarmee tegenaanloop niet bepaald beginnerqueries, dus wat dat betreft is het een minder relevant nadeel

Omdat je via PHPadmin allerlei opdrachten op je tabel kunt loslaten door simpel te klikken, deze opdrachten kun je zien, en kun je dan ook rechtsreeks in je php-bestand gebruiken.

Voor postgresql is er o.a. phppgadmin of de windowstool pgadmin

Eigenlijk heb ik sinds dag 1 zo gewerkt, gewoon in MySQL kijken wat ik moet doen om bepaalde rijen te selecteren, en dan de opdracht doorlezen, en deze dan gebruiken als ondersteuning voor mijn php script.

Je queries los invoeren en testen is inderdaad een handige methode om zo fouten te voorkomen, zeker als het een wat lastiger geval is. Maar hoewel phpmyadmin daar zeker een nuttig hulpmiddel bij is in geval van mysql, is het niet de enige die je daarbij kan helpen en kennen de andere rdbms-omgevingen ook dergelijke tools

lier schreef op vrijdag 06 juli 2007 @ 08:17:
Ik ken Postgresql (praktisch gezien) helemaal niet, maar ondersteund deze ook triggers ?

Al jaren, volgens mij is MySQL de enige veelgebruikte database die dat soort features pas sinds kort heeft of pas in de aankomende major release gaat krijgen

- voeg een veld toe aan de tabel waarin een timestamp van de insert (/update ?) komt.
- laat dit veld automatisch zetten door de trigger.

Hier heb je geen triggers voor nodig. Je kan zoiets overigens ook gewoon met een serial (postgresql), generator (diverse andere omgevingen) of auto_increment (mysql, mssql) oplossen. Of een timestamp-veld dat default naar de huidige tijd.
't Voordeel van de trigger is dan meer dat je die waarde kan forceren, ongeacht wat er bij de insert of update ingevoerd wordt.

[ Voor 12% gewijzigd door ACM op 06-07-2007 08:36 ]