[php] data uit een tabel ontleden

[EnsconcE]

Ik heb een tabel met daarin 1;2;3 en deze data zou ik willen ontleden door de 1 apart te gebruiken de 2 en de 3.
Ik heb al gezocht op internet en ik heb weinig kunnen vinden. Aangezien mijn kennis niet al te super is zou ik niet precies weten waarop ik zou moeten zoeken.

[Verwijderd]

explode(";",$data);

zoek maar in manual

[Rickbv]

Zie de functie "explode" in PHP, dan moet je er toch wel uit kunnen komen.

Ik snap alleen nog niet waar je dit voor nodig hebt in SQL (neem ik aan)? Het systeem was toch dat er maar 1 waarde in 1 veld hoort?

edit:

te laat

[ Voor 10% gewijzigd door Rickbv op 11-03-2003 22:33 ]

[marty]

ja, een database is er juist voor data geordend op te slaan en allemaal in aparte vakjes. dan moet je dus niet data die los van elkaar staat in 1 veld bij elkaar gaan zetten. Dan kun je net zo goed alles in een textfile gaan pleuren

[whoami]

Ik geloof dat je bv voor een bepaald record in een tabel meerdere waarden of gerelateerde id's wilt bijhouden?

Waarom stop je die niet in een andere tabel die je joined met de tabel die je al hebt?

[MBV]

hij heeft natuurlijk een oude database die hij wil converten naar een die wel aan de eerste normaalvorm voldoet

Je kan explode gebruiken om het te converteren naar tabel 2 met daarin 1, 2, 3 in aparte kolommen. Kom je er dan niet uit, dan zou ik je willen aanraden om een boek over databases aan te schaffen.

[EnsconcE]

ik ben bezig met een webwinkel en om zo weinig mogelijk tabellen te krijgen met zoveel mogelijk een uniek id, gooi ik de produkten die besteld zijn in 1 tabel dmv 1;3;5 waar de 1 3 en 5 de produkt id's zijn, nou wil ik deze erdus uithalen om later te kunnen zien wat mensen besteld hebben

ik heb ook nog een andere mogelijkheid maar dit leek mij de beste

[ Voor 12% gewijzigd door EnsconcE op 11-03-2003 22:59 ]

[whoami]

EnsconcE schreef op 11 March 2003 @ 22:56:
ik ben bezig met een webwinkel en om zo weinig mogelijk tabellen te krijgen

Waarom wil jij zo weinig mogelijk tabellen? Wat is het nut daarvan?
Ik raad je toch aan om eens eea te lezen over datamodellering en normaalvormen enzo...

met zoveel mogelijk een uniek id, gooi ik de produkten die besteld zijn in 1 tabel dmv 1;3;5 waar de 1 3 en 5 de produkt id's zijn, nou wil ik deze erdus uithalen om later te kunnen zien wat mensen besteld hebben

Van een slecht design gesproken.
Waarom niet een tabel 'Order' met de info over de bestelling (wie besteld heeft, wanneer, ...) en een tabel 'Orderregel' die aan elkaar gelinked zijn, en een link met de producten-tabel. In de tabel 'Orderregel' heb je dan voor iedere order, per product dat besteld is een record, met daarin het aantal dat besteld is enzo....

[EnsconcE]

whoami schreef op 11 March 2003 @ 23:00:
[nohtml]
[...]

Waarom wil jij zo weinig mogelijk tabellen? Wat is het nut daarvan?
Ik raad je toch aan om eens eea te lezen over datamodellering en normaalvormen enzo...

om die unieke id's aan te houden, dit leek mij veel makkelijker.

[...]
[/nohtml]

Van een slecht design gesproken.
Waarom niet een tabel 'Order' met de info over de bestelling (wie besteld heeft, wanneer, ...) en een tabel 'Orderregel' die aan elkaar gelinked zijn, en een link met de producten-tabel. In de tabel 'Orderregel' heb je dan voor iedere order, per product dat besteld is een record, met daarin het aantal dat besteld is enzo....

ik heb de table bestelling met daarin: wie besteld heeft, wanneer, en een uniek id, nou zit ik zelf alleen met het probleem om meerdere gegevens tegelijk aan de database toe te voegen en daarom ben ik op dit idee overgestapt, over m'n database hoef je je weinig zorgen te maken, dees zit goed in elkaar.

[whoami]

EnsconcE schreef op 11 March 2003 @ 23:08:
[...]

om die unieke id's aan te houden, dit leek mij veel makkelijker.

Neen, dat is het niet.... Anders had je nu dit probleem niet.

ik heb de table bestelling met daarin: wie besteld heeft, wanneer, en een uniek id, nou zit ik zelf alleen met het probleem om meerdere gegevens tegelijk aan de database toe te voegen en daarom ben ik op dit idee overgestapt, over m'n database hoef je je weinig zorgen te maken, dees zit goed in elkaar.

Tuurlijk hoef ik me geen zorgen te maken. Het is jouw probleem.
Echter, jouw database zit echt niet goed in mekaar.
Als je begint met meerdere waarden in 1 veld te stoppen, dan kan je met 100% zekerheid zeggen dat je datamodel aan geen kanten klopt.

[gorgi_19]

EnsconcE schreef op 11 March 2003 @ 23:08:
[...]

om die unieke id's aan te houden, dit leek mij veel makkelijker.

Om helemaal door te redeneren.. Het zou dan het mooiste zijn om 1 tabel aan te houden; 1 unieke ID. Om het nog sterker te vertellen, je hebt dan niet eens een database nodig. Een tekstbestand voldoet in dit opzicht dan opeens ook perfect.

ik heb de table bestelling met daarin: wie besteld heeft, wanneer, en een uniek id, nou zit ik zelf alleen met het probleem om meerdere gegevens tegelijk aan de database toe te voegen en daarom ben ik op dit idee overgestapt, over m'n database hoef je je weinig zorgen te maken, dees zit goed in elkaar.

Mooi. Kan je me dan de query geven, welke personen dan productID 2 hebben besteld in de maand mei? Vervolgens wil ook de kwartaaloverzichten van de verkopen, gegroepeerd per maand.
Of een andere. Iedereen die productID 3 heeft besteld, krijgt automatisch productID 5 erbij; dit geldt voor alle bestellingen die nog niet verstuurd zijn.

Dit ga je heel erg lastig voor elkaar krijgen.

En ik maak me idd geen zorgen over jouw databasedesign. Jij moet er mee werken, en jij komt voor de problemen te staan.

En wat is er mis met meerdere insert statements achter elkaar? Wat is er mis met een rij? Bang dat je database uit 10000 rijen gaat bestaan? (10.000 rijen is in de meeste gevallen niet veel, zeg maar weinig zelfs. )

[ Voor 31% gewijzigd door gorgi_19 op 11-03-2003 23:16 ]

[whoami]

Of hoe ga je bijhouden hoeveel stuks een bepaalde persoon van productid 3 heeft besteld in die ene bestelling?

[EnsconcE]

gorgi_19 schreef op 11 March 2003 @ 23:12:
[...]


Om helemaal door te redeneren.. Het zou dan het mooiste zijn om 1 tabel aan te houden; 1 unieke ID. Om het nog sterker te vertellen, je hebt dan niet eens een database nodig. Een tekstbestand voldoet in dit opzicht dan opeens ook perfect.


[...]

Mooi. Kan je me dan de query geven, welke personen dan productID 2 hebben besteld in de maand mei? Vervolgens wil ook de kwartaaloverzichten van de verkopen, gegroepeerd per maand.
Of een andere. Iedereen die productID 3 heeft besteld, krijgt automatisch productID 5 erbij; dit geldt voor alle bestellingen die nog niet verstuurd zijn.

Dit ga je heel erg lastig voor elkaar krijgen.

En ik maak me idd geen zorgen over jouw databasedesign. Jij moet er mee werken, en jij komt voor de problemen te staan.

En wat is er mis met meerdere insert statements achter elkaar? Wat is er mis met een rij? Bang dat je database uit 10000 rijen gaat bestaan? (10.000 rijen is in de meeste gevallen niet veel, zeg maar weinig zelfs. )

het probleem met meerdere insert statements is dat ik niet weet hoe ik dat zou moeten doen, wat ik wel weet is dat dat met een loop moet gebeuren, maar hoe?

edit:

these's days i'm the pigeon

[whoami]

EnsconcE schreef op 11 maart 2003 @ 23:17:
[...]


het probleem met meerdere insert statements is dat ik niet weet hoe ik dat zou moeten doen, wat ik wel weet is dat dat met een loop moet gebeuren, maar hoe?

Hoe bedoel je?
Je weet niet hoe je een insert in een lus moet schrijven?

edit:

these's days i'm the pigeon

Neen, jij bent the statue.
(Ff goed visualiseren wat duiven doen op standbeelden enzo).

[EnsconcE]

whoami schreef op 11 maart 2003 @ 23:24:
[nohtml]
[...]

Hoe bedoel je?
Je weet niet hoe je een insert in een lus moet schrijven?

ben er al 8er hoe ik het moet doen, in een loop de insert statement maken

[...]
[/nohtml]

Neen, jij bent the statue.
(Ff goed visualiseren wat duiven doen op standbeelden enzo).

edit:

thanks guys, et werkt nu goed

[ Voor 8% gewijzigd door EnsconcE op 11-03-2003 23:43 ]

[thomaske]

EnsconcE schreef op 11 March 2003 @ 23:31:
thanks guys, et werkt nu goed

Hoe ziet je datamodel er nu uit, als ik vragen mag?

[EnsconcE]

er worden nu meerdere velden gemaakt met elk:
id, 1 produkt id, aantal, prijs, totaalprijs per produkt, datum, emailadres en uniek id
deze velden hebben dan ook weer et unieke id die iedere klant krijgt bij het bestellen
het unieke id word zo aangemaakt

code:

srand ((double) microtime() * 1000000);
$uniek_id = uniqid(rand());

voor zover ik weet krijg je dan een nummer die uniek is

[ Voor 12% gewijzigd door EnsconcE op 12-03-2003 00:53 ]

[a3konijn]

En waarom niet gebruik maken van de mogelijkheid die de meeste DBMS systemen al bieden om een uniek id te maken. Bijvoorbeeld auto-incremental id of zo iets??

[EnsconcE]

autoincrement gebruik ik, maar wat als iemand dan 5 verschillende produkten koopt die heeft dan 1,2,3,4 en 5 als unieke id's.

[gorgi_19]

* gorgi_19 heeft het idee dat er weinig klopt van je database ontwerp....

Tabel klanten
KlantID (int, identity)
Naam
Adres
E-mail

Tabel producten
ProductID (int, identity)
Productnaam
Prijs

Tabel facturen
FactuurID (int, identity)
KlantID
Datum

Tabel factuurregels
ProductID (gecombineerde sleutel met FactuurID)
FactuurID
aantal

* gorgi_19 is trouwens een beetje dufjes nu, maar het geeft een idee.

[ Voor 12% gewijzigd door gorgi_19 op 12-03-2003 01:05 ]

[EnsconcE]

gorgi_19 schreef op 12 March 2003 @ 01:04:
* gorgi_19 heeft het idee dat er weinig klopt van je database ontwerp....

Tabel klanten
KlantID (int, identity)
Naam
Adres
E-mail

Tabel producten
ProductID (int, identity)
Productnaam
Prijs
!ProduktCatagorieID!

!Tabel catagorie
!ProductCatagorieID (int, identity)!
!ProduktCatagorie!

Tabel facturen
FactuurID (int, identity)
KlantID == KlantEmail(omdattieuniekis)
Datum
!UniekID!

Tabel factuurregels
ProductID (gecombineerde sleutel met FactuurID)
FactuurID
aantal

* gorgi_19 is trouwens een beetje dufjes nu, maar het geeft een idee.

klopt ongeveer(gebruik ook andere benamingen) op de laatste na, die heb ik niet. ook heb ik nog produkt catagorie, want daar maak ik het menu van, vervolgens heb ik dan bij produkten ook nog produkt catagorie zodat wanneer je op ikzegmaarwat klikt, word de id die erachter zit doorgestuurt naar default.php die alles uit de produkt database haalt waar catagorie id ikzegmaarwatnummer is

waarom zou ik die laatste gebruiken, ik bedoel die gecombineerde factuurregel?

* EnsconcE ook dufjes, gaat morgen verder

[gorgi_19]

Per definitie kan er maar 1 producttype gefactureerd worden per factuur. Wel kan het voor meerdere aantallen zijn. (2 regels voor exact dezelfde inktcartridge is volstrekt onzinnig)

Je hebt ook nog een menuutje er bij? Dan wordt het een interessante opdracht..
Dan krijg je nog:
[menu]
MenuID
ParentID
Naam van het menu
...

En dan kan je aan de tabel producten nog een item:
MenuID toevoegen.

Op deze manier kan je een menuboom bouwen, met een oneindig aantal subcategorieen.

[dusty]

EnsconcE schreef op 12 maart 2003 @ 01:15:
[...]
waarom zou ik die laatste gebruiken, ik bedoel die gecombineerde factuurregel?
[..]

Heb jij al een keer wat gelezen over normalisatie?

[Verwijderd]

Volgensmij heeft de TS nog steeds geen enkel idee wat iedereen nou de hele tijd aan zijn verstand probeerd te peuteren.
Tip: Sla de adviezen van iedereen met duidelijk een stuk hoger niveau van kennis niet in de wind, je komt jezelf echt een keer tegen. 1 keer leren nu bespaart je erg veel later. Zo had je bijvoorbeeld dit hele topic niet nodig gehad, geen rare constructies voor explodes en id's, en een model waarmee je altijd alle bewerkingen kan doen die er later bij mogen komen.
Kijk bijvoorbeeld eens hier: http://www.phpbuilder.com/columns/barry20000731.php3

[EnsconcE]

dusty schreef op 12 March 2003 @ 07:25:

[...]

Heb jij al een keer wat gelezen over normalisatie?

Ja en ik heb er zelfs een toets over gehad, ook in mijn tabel zitten primary keys en foreign keys en ja mijn database zit redelijk goed in elkaar. Ik moet alleen zeggen dat et m'n beste vak niet was, maar een 7 voor het bouwen van een database in access noem ik toch niet verkeerd. ik zal het waarschijnlijk niet perfect doen.

gorgi_19 schreef op 12 March 2003 @ 01:22:
Per definitie kan er maar 1 producttype gefactureerd worden per factuur. Wel kan het voor meerdere aantallen zijn. (2 regels voor exact dezelfde inktcartridge is volstrekt onzinnig)

Je hebt ook nog een menuutje er bij? Dan wordt het een interessante opdracht..
Dan krijg je nog:
[menu]
MenuID
ParentID
Naam van het menu
...

En dan kan je aan de tabel producten nog een item:
MenuID toevoegen.

Op deze manier kan je een menuboom bouwen, met een oneindig aantal subcategorieen.

sub catatgorieen heb ik niet nodig, wel heb ik het op ongeveer die manier gedaan zoals jij het hebt gedaan.
In m'n tabel factuur kom je per produkt, per klant per uniek id, 1 artikel tegen met de mogelijkheid om er meerdere van te kopen, je krijgt ook in die tabel de prijs per produkt en de totaalprijs per produkt. mocht ik dan later de prijzen veranderen van het produkt dat die klant gekocht heeft dan kan ik altijd nog in de tabel factuur kijken voor wat voor prijs diegene hem gekocht heeft in bv. 2002

Verwijderd schreef op 12 March 2003 @ 07:49:
Volgensmij heeft de TS nog steeds geen enkel idee wat iedereen nou de hele tijd aan zijn verstand probeerd te peuteren.
Tip: Sla de adviezen van iedereen met duidelijk een stuk hoger niveau van kennis niet in de wind, je komt jezelf echt een keer tegen. 1 keer leren nu bespaart je erg veel later. Zo had je bijvoorbeeld dit hele topic niet nodig gehad, geen rare constructies voor explodes en id's, en een model waarmee je altijd alle bewerkingen kan doen die er later bij mogen komen.
Kijk bijvoorbeeld eens hier: http://www.phpbuilder.com/columns/barry20000731.php3

hoezo sla ik adviezen in de wind, ik vraag alleen waarom je die gecombineeerde factuurregel zou gebruiken, sorry laten we het beter zeggen:
Hoe bedoel je dat die gecombineerde factuurregel? ik snap namelijk niet wat je ermee bedoelt.