VNC stopt er mee :(
sorteren mysql
1.1.2.5
1.1.2.6
1.1.2.10
1.1.2.11
Als ik deze kolom sorteer, dan sorteert hij het als 10,11,5,6 maar het is de bedoeling dat het 5,6,10,11 wordt. Ik kan in de mysql handleiding hiervoor niets vinden. Als het om gewone getallen zou gaat zou ik er volgens mij een INT veld van moeten maken, maar dat gaat nu niet op.
Wie weet een manier om dit goed gesorteerd te krijgen?
werkt dit niet.. verander dan DESC in ASC :P
Gewijzigd op 01/01/1970 01:00:00 door Leroy Boerefijn
Die voorloopnul ontloop ik het liefste, is er geen manier om het zonder voorloopnul te sorteren?
Ik had gehoopt dat er mss iets zou zijn waarmee het toch kon, dan zal het toch via die voorloopnul moeten. :(
i.i.g. bedankt voor de reakties.
Quote:
Wat is de betekenis van deze data? Is er een verband tussen 1.1.2.5 en 1.1.2.6 ? (lijkt mij wel, je wilt er tenslotte op sorteren)1.1.2.5
1.1.2.6
1.1.2.10
1.1.2.11
1.1.2.6
1.1.2.10
1.1.2.11
Mocht dat het geval zijn, dan is het datamodel niet correct en heb je de boel op een verkeerde manier opgeslagen. Het probleem met sorteren is dan het eerste probleem dan de vele, vele problemen die je nog gaat tegenkomen. Het is zelfs maar de vraag of je alle problemen kunt oplossen zonder het datamodel aan te passen.
Ik ben nieuwsgierig.
Ik wil dus graag dat het id mij gelijk verteld waar dit "record" in de piramide thuishoort.
Dus, het eerste getal is de laag van de piramide, het tweede getal het blok, het derde getal is dus een van de 8 delen, en het laatste getal een van de 16 delen.
Ik hoop dat je iets snapt van wat ik wil bereiken, maar zoals ik al zei, het is wat lastig uitleggen. :P
Ik sluit me aan bij die 'voorloop 0' :)
Je maakt nu een piramide, denk bv. aan een inhoudsopgave, waarbij geen enkel verband zit tussen de verschillende onderdelen. 1.1.2.6 heeft geen enkel verband met 1.2.1.1 en dat terwijl ze beide beginnen met een 1 (bv. hoofdstuk 1). Wanneer jij dit met jouw huidige datamodel wilt gaan oplossen, zul je hele lastige workarounds moeten gaan maken. En ik kan je nu al de garantie geven dat jouw systeem straks zal bezwijken onder deze workarounds. Spreek uit ervaring...
De enige manier om dit op te lossen, is om met een koppeltabel aan te geven welke records met elkaar zijn verbonden. Op deze manier kun je het verband gaan aangeven.
Voorbeeldje:
Tabelnaam content:
- id (INT, auto_increment)
- content (TEXT)
Tabelnaam: koppeling
- id (INT, auto_increment)
- id_parent_content (INT, foreignkey op id van tabel content)
- id_child_content (INT, foreignkey op id van tabel content)
- sortering (TINYINT)
UNIQUE(id_parent_content, id_child_content)
UNIQUE(id_parent_content, id_child_content, sortering)
Met dit datamodel krijg je een verband tussen de diverse records. Een record zonder parent is dus het hoofdstuknummer, een record met parent is een paragraaf. Op deze manier kun je altijd zien welke record nu bij welke parent hoort en wat het onderlinge verband is.
Met de kolom 'sortering' kun je aangeven hoe er moet worden gesorteerd. 5 parent records zullen bv. vast wel een bepaalde sortering moeten hebben. Hiervoor kun je simpel een getal nemen, maar ook een aanmaak datum/tijd zou kunnen voldoen. Net wat je nodig hebt. Dit geldt uiteraard ook voor de childs.
Gebruik wel de innoDB-engine van MySQL, anders kun je geen foreignkey's gebruiken.
Ook moet je niet vergeten om de UNIQUE's goed op te geven, anders kun je weer hopeloos in de problemen komen. Dit is overigens afhankelijk van jouw toepassing, wanneer een child aan meerdere parents kan worden gekoppeld heb je een andere constraint nodig dan met slechts 1 parent.
Ik moet de rest van je verhaal nog even laten bezinken, omdat dat iets dieper in MySQL gaat dan ik doorgaans gebruik. :)
Quote:
Dat zeg jij, maar de database weet daar niets van af. Kortom, er is geen verband!Er wellicht geen direct verband, maar als je bijv. 2.1.8.16 en 2.2.1.5, dan is het verband dat ze beide in dezelfde laag zitten van de piramide. Ze beginnen immers beide met 2.
Zolang jij geen foreignkey's gaat gebruiken, zal er namelijk geen verband ontstaan. Er zijn overigens wel wat variaties mogelijk op het voorbeeld dat ik heb gegeven, dit zal zeker niet in alle geval 'het beste' datamodel zijn.
Maar zonder foreignkey's kun je het datamodel wel als 'fout' bestempelen. Dit wil overigens niet zeggen dat het dan niet zal werken, maar je maakt het jezelf onnodig moeilijk en je gaat risico's lopen met de data-integriteit.
Ik heb er nog eens over na zitten denken, maar ik zie niet zo goed waar het mis kan gaan als ik mijn oorspronkelijke plan volg.
De waarden van 2.2.1.5 etc, veranderen niet, alleen andere velden in deze tabel. Er wordt dan bijv. met die 2.2.1.5 vanuit een ander veld in die tabel een relatie gelegd met een member_id uit een andere tabel.
Ik had ook alle vakken in de pyramide een nummer kunnen geven, en dan had het gewoon gewerkt als een "normaal" id veld, alleen dit leek mij overzichtelijker, en kan dan ook een harde verwijzing vanuit mijn PHP script maken.
Ik bedoel dit niet eigenwijs hoor, misschien begrijp ik ook nog niet helemaal waar jij precies op doelt, enige wat ik aan wil geven is dat ik niet begrijp waar het bij mij mis zal gaan. :)
Quote:
Je zegt dus eigenlijk dat de waarde 2.2.1.5 zo richting het grof vuil kan omdat je dit gegeven, de koppeling met andere gegevens, al ergens anders hebt gemaakt. Gooi deze zooi dan ook zo snel mogelijk weg! Gegevens 2x in de database opslaan, zorgt altijd voor inconsistente data.De waarden van 2.2.1.5 etc, veranderen niet, alleen andere velden in deze tabel. Er wordt dan bijv. met die 2.2.1.5 vanuit een ander veld in die tabel een relatie gelegd met een member_id uit een andere tabel.
En de uitspraak 'veranderen niet' is een gevaarlijke, deze is al achterhaald voordat jouw systeem klaar is. Ik spreek uit ervaring!
Maar nogmaals, ga normaliseren. Het gegeven '2.2.1.5' bestaat uit meerdere gegevens, 4 stuks om precies te zijn. En meerdere gegevens sla je in een relationele database nooit en te nimmer op in 1 record. Het datamodel is gewoon fout, jouw sorteerprobleem is 1 van de vele, vele problemen die je gaat tegenkomen. Performance is bv. ook een probleem waar je tegenaan gaat lopen, jij hebt straks veel LIKE-vergelijkingen nodig voor de queries. Deze kosten onnodig veel tijd omdat er geen index kan worden gebruikt.
2 goede artikelen over normalisatie:
http://yapf.net/Articles/ArticleView/789
http://www.phphulp.nl/php/tutorials/3/150/
Ik ga het flink onder de loep nemen. En eens een paar verschillende opzetten uitdenken.
Ik ben het overigens niet eens met je stelling dat ik 2x dezelfde gegevens in de db opsla. Ieder gegeven komt maar 1x voor. Ook ben ik het niet eens met de LIKE-vergelijkingen, omdat ik van te voren weet welk id (zoals 2.1.2.5) ik moet aanroepen.
Ik denk dat dit voornamelijk komt doordat ik de code die ik aan ieder onderdeel van de pyramide "hang" als 1 gegeven zie, en jij als meerdere gegevens. Strict genomen heb jij daarin gelijk omdat je de data kunt opsplitsen en ieder getal dan ergens voor staat. Echter, ik wil het alleen als geheel gebruiken als identifier voor een stukje van de pyramide. Normaal gesproken had ik dus een id-veld met auto_increment genomen, maar daar doe ik dit nu dus voor in de plaats.
Neemt niet weg dat ik je advies ter harte neem, en ik ga zo de links die je hebt gepost goed doornemen. Ik wil er ook bij zeggen dat ik niet de indruk wil wekken het beter te weten dan jij. Ik probeer alles alleen maar te begrijpen en aan te geven dat ik toen ik dit had uitgedacht er een heel andere filosofie achter had dan zoals jij het nu voorstelt. :)
@Blanche
Ja klopt, die sortering is een probleem, maar zou wel op te lossen zijn door een voorloopnul. Maar met een voorloopnul zal niet gelijk mijn hele database inconsistent zijn. Wat ik eigenlijk wil zeggen... als die voorloopnul alles is dan vind ik dat nog niet zo'n ramp. Ik doelde natuurlijk ook op andere problemen, dat van die voorloopnul was al duidelijk geworden in de voorgaande posts. :)
Gewijzigd op 01/01/1970 01:00:00 door Wim
[CONSTRAINT symbol] FOREIGN KEY [id] (index_col_name, ...)
REFERENCES tbl_name (index_col_name, ...)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
Heeft iemand een voorbeeld hoe je dit invult?
Wat vul je bijv. in bij symbol, of id, etc.
Hoe gebruik je dit zo effectief mogelijk. Ik begrijp wel waarvoor je het gebruikt, maar niet hoe je het op de juiste wijze toepast (rekening houdend met de opties in de syntax).
Wie wil mij een zetje in de juiste richting geven?