![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link.png){kind=icon}
[Project MediaDB] Inleiding + de eerste stappen
Vorige week heb ik een koffer gekocht waar ik al mijn cd's en dvd's in kan opbergen. Het voordeel is natuurlijk dat je ineens heel veel ruimte overhoudt. Maar het grote nadeel is op het eerste gezicht, dat je niet meer wat waar zit, en wat er allemaal wel en niet in zit.
Daarom heb ik het idee bedacht om een web based applicatie te gaan bouwen in PHP. Voor gegevens opslag had ik 2 mogelijkheden. Namelijk een array of een database. Ik heb hier gekozen voor een database omdat ik zo in de toekomst meer mogelijkheden heb met betrekking tot het uitbreiden, en het toevoegen van functies waar de database moet worden uitgebreid.
Voor de applicatie heb ik de volgende basis functies in gedachten:
De eerste stap was het aanmaken van een database. Deze krijgt 3 velden zoals hieronder is te zien:
Ook heb handmatig al wat films toegevoegd aan de database:
Komende tijd ga ik beginnen met de PHP. Ik begin met de overzichten, en zal dit later uitbreiden met toevoegen, wijzigen en verwijderen.
Mochten jullie nog ideeën hebben over toekomstige functies of een goede naam weten voor de applicatie dan kunnen jullie die kwijt in de reactie's.
Daarom heb ik het idee bedacht om een web based applicatie te gaan bouwen in PHP. Voor gegevens opslag had ik 2 mogelijkheden. Namelijk een array of een database. Ik heb hier gekozen voor een database omdat ik zo in de toekomst meer mogelijkheden heb met betrekking tot het uitbreiden, en het toevoegen van functies waar de database moet worden uitgebreid.
Voor de applicatie heb ik de volgende basis functies in gedachten:
- Toevoegen items
- Wijzigen items
- Verwijderen items
- Overzicht presenteren per catogorie
- Zoek functie
De eerste stap was het aanmaken van een database. Deze krijgt 3 velden zoals hieronder is te zien:
Ook heb handmatig al wat films toegevoegd aan de database:
Komende tijd ga ik beginnen met de PHP. Ik begin met de overzichten, en zal dit later uitbreiden met toevoegen, wijzigen en verwijderen.
Mochten jullie nog ideeën hebben over toekomstige functies of een goede naam weten voor de applicatie dan kunnen jullie die kwijt in de reactie's.
![Volgende: [Project MediaDB] Update #1](http://tweakimg.net/g/bullets/arrow_up.gif){kind=icon} 05-'09
|
[Project MediaDB] Update #1 |
 03-'09
|
Stop de verzadiging |
Reacties
Door
pythagorasABC,
dinsdag 07 april 2009 23:31
Je kent meuk: All My Movies 5.4 build 1281 ?
Ik weet alleen niet of je daar muziek cd's aan kan toevoegen.
Ik weet alleen niet of je daar muziek cd's aan kan toevoegen.
Door
rusman,
dinsdag 07 april 2009 23:35
Ja, ik ken inderdaad het programma via de meuk. Alleen heb ik het nog nooit bekeken. Heb dus ook geen idee of ik ook een fysieke locatie kan aangeven van iets. Verder ligt mijn ideen wel een beetje in die richting inderdaad. Maar ik wil het graag web based hebben zodat ik het ook makkelijk vanaf een andere locatie kan benaderen om te kijken of ik iets in huis heb. Toch bedankt voor je tip, ik zal het programma eens installeren om wat inspiratie op te doen!
Door
Kwastie,
dinsdag 07 april 2009 23:36
De database houd zich ook niet aan de Database normalisatie 'regels'. (Dus data zoals 'categorie' maar 1x opslaan)
Door
rusman,
dinsdag 07 april 2009 23:40
Hmm, ja hoe zou ik het dan moeten doen? Tabel aanmaken met categorieën, en dan categorie id per record meegeven?
Door
TeeDee,
dinsdag 07 april 2009 23:47
@rusman: onder andere. Een film of muziek entiteit kan onder meerdere categorieën vallen.
Maar hoe kom je op het idee om het e.e.a. in een array op te slaan en waar? Een array van wat? 1 groot XML- tekst of wat dan ook?
Maar hoe kom je op het idee om het e.e.a. in een array op te slaan en waar? Een array van wat? 1 groot XML- tekst of wat dan ook?
Door
rusman,
dinsdag 07 april 2009 23:49
Een item kan maximaal onder 1 categorie vallen, verder sla ik het niet op in een array of xml bestand maar in een database. Hier zal dus ook nog een tabel categorie in komen waarin de mogelijke categorieën komen te staan.
Door
GrooV,
woensdag 08 april 2009 01:22
@rushman
Ik zou in je database ontwerp maar zo veel mogelijk rekening houden met uitbreidingen, want misschien wil je dit later wel en dan is het een pain in the ass om het nog aan te passen. Daarom moet je de normalisatie regels aanhouden.
Als je categorieën apart houdt kan je er ook makkelijker op filteren enzo, maakt het allemaal net iets sneller als de database vol begint te raken.
Ik zou in je database ontwerp maar zo veel mogelijk rekening houden met uitbreidingen, want misschien wil je dit later wel en dan is het een pain in the ass om het nog aan te passen. Daarom moet je de normalisatie regels aanhouden.
Als je categorieën apart houdt kan je er ook makkelijker op filteren enzo, maakt het allemaal net iets sneller als de database vol begint te raken.
Door
RobIII,
woensdag 08 april 2009 02:24
Vooral doen; dan komt V1 in 2018 wel klaarIk zou in je database ontwerp maar zo veel mogelijk rekening houden met uitbreidingen
Gewoon wél goed overdenken, maar zeker niet alles willen vangen of enorm op de toekomst gebrand zitten prutsen: YAGNI
Met een goed doordacht ontwerp (maar dus niet over-engineered of dusdanig 'breed' opgezet dat je "alles" er mee kunt) juist niet. Juist als je een "zo veel mogelijk rekening houden met uitbreidingen"-database hebt krijg je die zeik.Ik zou in je database ontwerp maar zo veel mogelijk rekening houden met uitbreidingen want misschien wil je dit later wel en dan is het een pain in the ass om het nog aan te passen.
Euh; nee. Niet omdat het een pain in the ass is om aan te passen. Nee; die reden kende ik nog niet. Het staat gewoon in de eerste paragraaf van Wikipedia die hierboven nog genoemd wordt hoorIk zou in je database ontwerp maar zo veel mogelijk rekening houden met uitbreidingen. Daarom moet je de normalisatie regels aanhouden.~~
Maar ik vind de EN versie (zoals meestal) stukken compacter en mooier:Databasenormalisatie is een hulpmiddel bij het ontwerpen van gegevensbanken. Oorspronkelijk begonnen als noodzaak om data in een database te kunnen opslaan in het beperkte geheugen van de toenmalige computers, heeft databasenormalisatie zijn eigen rechtvaardiging gekregen.
Door herhaalde gegevens in een tabel apart op te slaan in een gerelateerde tabel is het mogelijk niet alleen het dubbel opslaan van gegevens te vermijden, maar vooral ook is het mogelijk foute verdubbelingen te voorkomen. Zo kunnen plaatsnamen bij adresgegevens in een aparte tabel opgenomen worden waardoor verkeerde spelling vermeden kan worden. Maar ook blablabla...
In the field of relational database design, normalization is a systematic way of ensuring that a database structure is suitable for general-purpose querying and free of certain undesirable characteristics—insertion, update, and deletion anomalies—that could lead to a loss of data integrity
Euh:Als je categorieën apart houdt kan je er ook makkelijker op filteren enzo
SQL:
1 | Select * from MyTable Where categorie = 'serie'
|
What's the difference
Je bewering bevat wel een kern van waarheid, maar zoals je 't nu brengt is het gewoon plain wrong Als je je ook nog eens gaat bezig houden met dat soort micro-optimalisaties dan ben je al helemaal verkeerd bezig. Begin eerst maar eens met indexes juist en "op rake plekken" te plaatsen; daar heb je een factor 10 miljoen meer aan.maakt het allemaal net iets sneller als de database vol begint te raken
[Reactie gewijzigd op woensdag 08 april 2009 09:42]
Door
RobIII,
woensdag 08 april 2009 02:27
^ Potdorie, nogal wat scheef gegaan hier 
@rusman: knal die edit optie eens aan?
@rusman: knal die edit optie eens aan?
Door
Sebazzz,
woensdag 08 april 2009 07:48
Leuk tooltje Rusman, leuk dat je erover gaat bloggen
@RobIII: Jij kan bij de database komen, niet zeiken
@RobIII: Jij kan bij de database komen, niet zeiken
Door
rusman,
woensdag 08 april 2009 09:37
@Roblll: Daar dacht ik vannacht ook dus over na. In principe komen er maar een paar categorieën. Namelijk: film, serie, muziek, software. Nu kan ik dit wel in een tabel gaan zetten als
1 Film
2 Serie
3 Muziek
4 Software
Maar wat is het verschil tussen
code:
Precies zoals jij ook beschrijft hierboven. Volgens mij als je zo bezig gaat, moet je ook in een users tabel een speciale tabel maken voor geslacht. Verder is het ook zo, dat wanneer je een aparte tabel zou maken voor categorie, je dan meer code in de query nodig hebt. Dus wie overtuigt mij?
1 Film
2 Serie
3 Muziek
4 Software
Maar wat is het verschil tussen
code:
1
2
| Select * from Overzicht Where categorie = "serie' Select * from Overzicht Where categorieid = 3 |
Precies zoals jij ook beschrijft hierboven. Volgens mij als je zo bezig gaat, moet je ook in een users tabel een speciale tabel maken voor geslacht. Verder is het ook zo, dat wanneer je een aparte tabel zou maken voor categorie, je dan meer code in de query nodig hebt. Dus wie overtuigt mij?
Door
RobIII,
woensdag 08 april 2009 09:55
@Sebazzz: Nee hoor. Ik mag dan wel mod zijn; dat betekent niet automatisch dat ik bij de DB kan (En logisch...) Of kun jij ook bij de loonadministratie bij de Appie? Daar werk(te?) je toch?
@rusman: Zoals ik al aangaf in mijn post (thanks voor de edit-mogelijkheid ) heeft het normaliseren wel degelijk nut; alleen was het om de verkeerde redenen die aangegeven werden. Je wil wel degelijk een 'categorie' tabel; anders krijg je straks dit:
code:
Even wat overdreven maar je hebt nu dus (bijv) Serie en serie en een typo: "seie". Alle 3 serie. En dan heb je Film en film en Meziek, Muziek en muziek. Dat wordt uiteindelijk een puinhoop. Zeker als je straks "Muziek" wil gaan aanpassen naar "Audio" ofzo want dan mis je een aantal records bij het updaten.
Nu is dit natuurlijk een gechargeerd voorbeeld en wat overdreven, maar de kans dat je dit soort 'rommel' krijgt is wel erg hoog
(En logisch...) Of kun jij ook bij de loonadministratie bij de Appie? Daar werk(te?) je toch?@rusman: Zoals ik al aangaf in mijn post (thanks voor de edit-mogelijkheid
) heeft het normaliseren wel degelijk nut; alleen was het om de verkeerde redenen die aangegeven werden. Je wil wel degelijk een 'categorie' tabel; anders krijg je straks dit:code:
1
2
3
4
5
6
7
8
9
| Film A Film Nummer A Muziek Film B Film Serie A Serie Film C film Serie B seie Serie C Serie Nummer B Meziek Nummer C muziek |
Even wat overdreven maar je hebt nu dus (bijv) Serie en serie en een typo: "seie". Alle 3 serie. En dan heb je Film en film en Meziek, Muziek en muziek. Dat wordt uiteindelijk een puinhoop. Zeker als je straks "Muziek" wil gaan aanpassen naar "Audio" ofzo want dan mis je een aantal records bij het updaten.
Nu is dit natuurlijk een gechargeerd voorbeeld en wat overdreven, maar de kans dat je dit soort 'rommel' krijgt is wel erg hoog
[Reactie gewijzigd op woensdag 08 april 2009 09:56]
Door
TeeDee,
woensdag 08 april 2009 10:12
Nog even over het 'array' gedoe.
Je zegt:
Edit @RobIII hieronder:
Je zegt:
Dat dat überhaupt in je opkwam vond ik vreemd. Vandaar m'n reactieVoor gegevens opslag had ik 2 mogelijkheden. Namelijk een array of een database.
Edit @RobIII hieronder:
[Reactie gewijzigd op woensdag 08 april 2009 10:34]
Door
RobIII,
woensdag 08 april 2009 10:26
Met een goeie abstractie laag boeit het niet eens of je een array of db gebruikt
Door
rusman,
woensdag 08 april 2009 10:44
Aha, ok! Nou ik zal eens even wat wijzigingen doorvoeren dus. Categorie tabel word aangemaakt, verder komt er ook nog een gebruikers tabel voor het login systeem wat er later nog in komt. Meer daarover komt in de volgende blog post.
Door
Sebazzz,
woensdag 08 april 2009 15:39
Ow sorry, ik dacht dat je devver was bij T.Net@Sebazzz: Nee hoor. Ik mag dan wel mod zijn; dat betekent niet automatisch dat ik bij de DB kan
En ik ken inderdaad bij de loonadministratie, ik ken namelijk credentials [Reactie gewijzigd op woensdag 08 april 2009 15:39]
Door
RobIII,
woensdag 08 april 2009 16:54
Mochten ze willenOw sorry, ik dacht dat je devver was bij T.Net
Door
JeRa,
woensdag 08 april 2009 23:22
Sterker nog, een aantal jaar geleden ben ik bezig geweest met een abstractielaag waarmee je queries kon samenstellen die net zo uitgebreid en complex konden worden als normale SQL-queries, maar dan puur met objecten in PHP. Zo'n 'querytree' aan objecten werd dan vervolgens aan de DB-laag meegegeven, waarbij ik een MySQL- en een FileDB-laag kon aanspreken.Met een goeie abstractie laag boeit het niet eens of je een array of db gebruikt
De MySQL class converteerde de queries netjes naar SQL en voerde ze uit, zoals normaal. De FileDB class interpreteerde de query tree, en besloot afhankelijk van de verschillende componenten in de query wat het meest gewenste uitvoerpad was. Zelfs zonder indices ging dat nog aardig rap
En de reden was vrij simpel; rond die tijd kreeg ik een aantal klanten die wél wilden betalen voor een mooie website, maar niét voor de hostingkosten. Leuk projectje geweest, maar inmiddels zeg ik gewoon nee tegen dat soort onzin
Door
RobIII,
donderdag 09 april 2009 02:02
With all due respect, maar 'net zo complex' durf ik te betwijfelen. Een beetje DBMS gaat heel ver in dat soort zaken en dat is niet iets wat je in je uppie effe zo in een paar weken bouwt. Dat je wat select/insert/update/delete en evt. wat where/aggregates en evt. zelfs grouping/unions etc. ondersteunt kan ik nog in komen, maar "net zo complex" lijkt me, to be honest, wat overdrevenSterker nog, een aantal jaar geleden ben ik bezig geweest met een abstractielaag waarmee je queries kon samenstellen die net zo uitgebreid en complex konden worden als normale SQL-queries
Soort ORM-wiel opnieuw uitgevonden dus?maar dan puur met objecten in PHP. Zo'n 'querytree' aan objecten werd dan vervolgens aan de DB-laag meegegeven...De MySQL class converteerde de queries netjes naar SQL en voerde ze uit, zoals normaal.
Die ze dus maar driedubbel voor 5 jaar hosting ophoestten in ontwikkelkosten?En de reden was vrij simpel; rond die tijd kreeg ik een aantal klanten die wél wilden betalen voor een mooie website, maar niét voor de hostingkosten.
Door
Toppe,
vrijdag 10 april 2009 14:16
Ben benieuwd, ben zelf ook al tijdje opzoek naar zoiets, heb er ook over gedacht zelf te maken, ben alleen geen held met HTML, php no problemo:P
Word het openbaar?
Word het openbaar?
Door
JeRa,
vrijdag 10 april 2009 17:48
Met 'net zo complex' bedoelde ik dat er in principe geen limiet was aan de 'diepte' van de query tree. Functionaliteiten die ik destijds niet nodig had kwamen er uiteraard ook niet inWith all due respect, maar 'net zo complex' durf ik te betwijfelen. Een beetje DBMS gaat heel ver in dat soort zaken en dat is niet iets wat je in je uppie effe zo in een paar weken bouwt. Dat je wat select/insert/update/delete en evt. wat where/aggregates en evt. zelfs grouping/unions etc. ondersteunt kan ik nog in komen, maar "net zo complex" lijkt me, to be honest, wat overdreven
Het ging niet zozeer om de mappings, maar om de abstractieSoort ORM-wiel opnieuw uitgevonden dus?
ik was bezig met een basis die ongeacht de storage backend een fatsoenlijke DB interface leverde.Ik was 15 of 16 ofzo, dus de ontwikkelkosten waren én verspreid én laag. Bovendien vond ik het gewoon leukDie ze dus maar driedubbel voor 5 jaar hosting ophoestten in ontwikkelkosten?
Door
rusman,
vrijdag 10 april 2009 20:13
Je zal nog wel even geduld moeten hebbenBen benieuwd, ben zelf ook al tijdje opzoek naar zoiets, heb er ook over gedacht zelf te maken, ben alleen geen held met HTML, php no problemo
Word het openbaar?
het is maar een side project waar ik aan werk als ik er zin in heb. Toch denk ik dat het niet heel lang gaat duren, aangezien ik ook iets af wil maken als ik ermee begin. En ja, hij zal openbaar worden zodra de eerste testversie klaar is. Vanaf dan zullen alle releases vrij te downloaden zijn.