gebruik van array's in een database??

[rlckring]

Gebruik van array's in een database??

 

Iemand ervaring daar mee?

 

Word het aanbevolen of toch liever een aparte tabelrij voor elke afzondelijke waarde. Het maakt toch niets uit... Als dan dat er anders veel tabelrijen komen.

 

Ik sta nu voor een keus. De tabelrij zou 8 kolomen bevatten. Zie het maar als een factuur met materialen waar bij je een tabel factuur hebt en een tabel materialen. Er kunnen per factuur meerdere materialen worden opgegeven, moet ik die dan opslaan voor elke materiaal met z'n prijs in 1 tabelrij of al die materialen opslaan in 1 array in 1 tabelrij gekoppeld aan de tabel factuur.

 

Alvast bedankt.

[Gast]

Als je verder niet hoeft te muteren zou het zo kunnen.

Plaats array bijv in memo field, en lees deze in waarneer je moet displayen in in een array.

 

Maar om zo te muteren is een crime.

 

Rebel

[rlckring]

Wijzigingen moeten wel plaats kunnen vinden. Het gaat met name of er fouten kunnen optreden of omdat er messchien performance verloren kan gaan.

 

Volgens mij gaat er ook performance verloren op het moment dat je elk materiaaltje, in dit geval, uit moet lezen uit meerdere tabelrijen als dan dat er 1 tabelrij word opgehaald en deze weet te exploderen naar een verwerkbare array.

 

Het zijn allemaal kleine waarden die opgeslagen moeten worden dus vandaar dat dit idee bij me op kwam. Ik vind het ergens een beetje zonde om dan ,voor elk materiaaltje met z'n prijs en het aantal ervan, een nieuwe tabelrij aan te maken.

 

 

Maar mutaties moeten foutloos kunnen in principe en zonder verlies van performance.

[Gast]

De performance gaat niet verloren volgens mij.

Je kunt de selectie in 1 keer maken met een join.(zie bijlage).

 

SELECT channels.*, transponders.*

FROM channels INNER JOIN transponders ON channels.transponder = transponders.transponder;

 

Lijkt me toch de beste oplossing.

 

Rebel

487119-mediasat1.zip

[rlckring]

Nou ik probeer het ff in een array alvorens ik voor ieder materiaaltje een tabel aanmaak. Dat voorbeeld van u, bedankt overigens, is een heel ander verhaal waarbij je inderdaad beter alles apart in een tabelrij kan opslaan. In mijn situatie gaat het niet om 2234 stuks materialen per factuur maar hooguit een stuk of 10. En als ik dat op kan slaan als text met een uniek scheidings teken vind ik het goed. Overigens kunnen de materialen gekozen worden uit een tabel waarbij ze wel weer elk in een aparte tabelrij staan.

 

Het werkt voorlopig aardig, pratijk zal het leren.....

[Gast]

Ik zou het toch bij het relationele model houden (zie voorbeeld Rebel). De meeste database engines zijn hierop juist gemaakt, je programma wordt een stuk flexibeler (bv: je zegt nu 'hooguit een stuk of 10' ... als je dit relationeel op slaat maakt het niet uit hoeveel materialen je aan een factuur wilt hangen) en qua omvang van je datatransfer maakt het niet veel uit.

 

Just my 2eurocents

[rlckring]

Ja daar viel ik ook eerst voor maar voor elke materiaal regel is het wel een Database-Query en dat zou dan zo op kunnen lopen tot 15 keer per factuur.

 

Wat is dan wijsheid?

[Gast]

Nee dat hoeft niet het principe is 1 to many dus zorg dat je order een uniek id heeft en dat je een database recordset maakt van de materialen met hetzelfde id.

 

Dan kun je de join in 1 keer maken, en heb je de alle records in 1 keer gezelecteert.

 

Rebel

[rlckring]

De gegevens ophalen kan volgens mij in 1 Query maar met opslaan niet. Met opslaan is er een loop die dan voor elke materiaaltje een update query uitvoerd.

 

Het gaat overigens over MySQl met php. Daarnaast heb ik een Javascript pagina gemaakt die voor de materiaal en arbeid, voor die factuur, client side tabelrijen invoegd. Elke tabelrij vertegenwoordigd een materiaal of arbeids regel. Waarin de artikel omschrijving, aantal, stuksprijs en totaalprijs worden gedefineerd. Als de client klaar is met invoeren/wijzigen klikt deze op oplsaan. Dan word er met $POST_ een getal meegegeven voor het aantal tabelrijen die de loop moeten lopen om de gegvens in de database op te slaan.

 

Nu heb ik het zo, dat ik er een uniek scheidingsteken voor elk artikelomschijving komt te staan en alle artikelomschijvingen komen dan in 1 tabelrij en in kolom Atrikel_omschr. Dat zelfde geld voor de aantallen, stuksprijzen e.t.c. Die zitten dan in de zelfde tabelrij maar in een andere kolom.

 

Dus stel we hebben 5 tabelrijen, dan heb ik nu 5 implodes i.p.v. 5 database query's.

 

Of zou u gaan voor 5 query's??

[Gast]

Ik persoonlijk zou de loop gebruiken om de records toe te voegen aan de database.

 

Met bijv. sql statement

Inser into Orders (OrderID, PartID, Description, Price, Quantity) VALUES (?, ?, ?, ?, ?)

 

Dus toch elk artikel zijn eigen rij.

 

Rebel

[Gast]

Stel je muteert 5 materiaalregels tegelijk. De gegevens van die regels moeten toch opgestuurd gaan worden. Of je nu 1 query verstuurd met de gegevens van die 5 regels of 5 querietjes maakt qua omvang niet veel uit.

MySQL kan echter die 5 querietjes sneller doorproppen dan een grote blob verwerken (intern), want het zijn allemaal 'fixed' veldjes + je neemt minder alvast-gereserveerde ruimte in (een database backend kan stukken beter schoffelen met veel kleine veldjes dan met een paar grote of -erger nog- variabele lengte velden).

 

Een ander voordeel van losse queries is dat je kunt gaan controleren wat er precies veranderd is (in je verzendform met Javascript), en alleen de veranderingen versturen. Bijvoorbeeld wanneer er in totaal 10 materiaalregels zijn en iemand wijzigd alleen de derde regel ... Met jouw constructie moet je dan toch alle 10 de regels versturen, in het geval van losse queries maar 1tje.

 

In ieder geval ben je met losse queries een stuk flexibeler bezig (1, 10, 100 regels, who cares?), helemaal als je de tabel-opbouw (gedeeltelijk) laat sturen door de opgehaalde recordsets. Je kunt dan bijvoorbeeld straffeloos een veldje toevoegen of van naam veranderen zonder dat je in de code moet gaan zitten grutten, dus je pagina wordt database gestuurd!

 

Groetjes, Richard

[rlckring]

Dat is klare taal Richard..

 

Citaat:

MySQL kan echter die 5 querietjes sneller doorproppen dan een grote blob verwerken (intern), want het zijn allemaal 'fixed' veldjes + je neemt minder alvast-gereserveerde ruimte in (een database backend kan stukken beter schoffelen met veel kleine veldjes dan met een paar grote of -erger nog- variabele lengte velden).

 

Bovenstaande bracht me aan het denken, en tot het herconstruëren van m'n code.

[rlckring]

Ik zag net dat Toxic[q] weer z'n query counter onderin ook weer aan heeft gezet!!

Wat zit ik dan te zaaniken over die query's, als ik eens kijk bij het Dreambox-forum, maar liefst 39 Query's.

 

Ik heb alles nu omgebouwd en tel zo'n 20 Query's, niet zeuren dus...

 

 

Bedankt voor de moeite, bovenstaanden....