Virusscanner tips?
Database setup
wat ik probeer te bereiken is het volgende. de user voegt zijn kind toe (table kind). Het kind wordt vervolgens aangemeld voor een bepaald event ( table inschrijving). vervolgens kan een moderator in inschr_adm table informatie toe te voegen zoals een aanwezigheid checklist, betaling etc. nu heb ik de volgende database in gedachten, maar twijfel of dit wel gaat werken. Graag jullie mening hierover.
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
role VARCHAR(20),
email VARCHAR(255) NOT NULL,
password VARCHAR(255) NOT NULL,
tokenhash CHAR(40) NOT NULL,
created DATETIME,
updated DATETIME
);
CREATE TABLE kind (
id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
created DATETIME,
updated DATETIME,
FOREIGN KEY user_key (user_id) REFERENCES users(id)
);
CREATE TABLE inschrijving (
id INT AUTO_INCREMENT,
kind_id INT NOT NULL,
users_id INT NOT NULL,
created DATETIME,
PRIMARY KEY (kind_id, user_id),
INDEX kind_idx (user_id, kind_id),
FOREIGN KEY kind_key(kind_id) REFERENCES kind(id),
FOREIGN KEY user_key(user_id) REFERENCES users(id)
);
CREATE TABLE inschr_adm
id INT AUTO_INCREMENT,
kind_id INT NOT NULL,
users_id INT NOT NULL,
PRIMARY KEY (kind_id, user_id),
INDEX kind_idx (user_id, kind_id),
FOREIGN KEY inschrk_key(kind_id) REFERENCES inschrijving(kind_id),
FOREIGN KEY inschru_key(user_id) REFERENCES inschrijving(users_id)
);
Ik zou in de tabel kind de kolom user_id hernoemen naar parent_user_id zodat zowel de rol van de verwijzing duidelijker is (en het user_id geeft aan waar de verwijzing betrekking op heeft).
Ik zie niet helemaal de toegevoegde waarde van de tabel inschr_adm.
Je zou bijvoorbeeld een kolom betaling_bevestigd kunnen toevoegen aan inschrijving.
Daarnaast heb je het over "aanwezigheids checklist" en heb je het over events. Betreft een "event" altijd een eenmalige bijeenkomst, of mogelijk meerdere.
Mogelijk helpt het volgende:
- schrap de tabel inschr_adm
- creeer een tabel events
- maak een verwijzing vanuit inschrijving naar events
- maak eventueel een tabel bijeenkomsten die je koppelt aan de events (een event bestaat uit 1 of meer bijeenkomsten)
- en vervolgens een koppeltabel "aanwezigheid" of "deelname" of "presentielijst" oid tussen de bijeenkomsten en de kinderen
zoiets?
Het struikelblok was waarschijnlijk dat je "event" en "inschrijving" als 1 en hetzelfde ding ziet?
EDIT: misschien doe je dit al, maar wat enorm kan helpen is zo'n ontwerp gewoon eens op papier kladderen, eea maak je dan een stuk visueler zodat je een beter totaaloverzicht hebt, en je wss sneller ziet waar je met dingen moet schuiven.
Gewijzigd op 11/04/2015 14:06:12 door Thomas van den Heuvel
Bedankt voor je reactie. Waar ik vooral over twijfel is het volgende; het zit hem voornamelijk vast op de inschrijving. Ik vraag mij af of iedere inschrijving een unieke id moet hebben. Het is tenslotte een jaarlijks event (kinderkamp), dat uiteindelijk zal het op jaar gefilterd worden. In de toekomst wil ik dan nog iets met de history gaan doen die je uiteindelijk verzameld, maar dat is voor nu nog niet belangrijk. Ook zit mijn twijfel bij het kiezen van de juiste index. Of het dan toch niet op basis van naam (of achternaam) zou moeten.
Het idee achter de inschr_adm is dat wij als bestuur kunnen aangeven dat er betaald is, of het kind aanwezig is etc. Zonder dat je dus daarbij aanpassingen kan maken aan het door de ouder ingevulde inschrijving. Meer het afschermen van gebruiker / moderator zeg maar.
Inderdaad heb ik het al ontelbare keren op papier gezet, heb nu ook niet alle inhoud mee gepost om het overzichtelijk te houden. Maar het is inderdaad een gouden tip!
Toevoeging op 11/04/2015 16:13:24:
Even in een notendop de app:
Met 60 enthousiaste vrijwilliger organiseren wij ieder jaar in de bouwvak een kinderkamp. van ouds her is de gedachte voor kinderen waarvan het de ouder niet al te breed hebben, toch een leuke vakantie kunnen geven. Nu werkt alles via wordpress in contactform 7. dat is wel zo gemaakt dat je er niks mee kan, tenzij je er voor betaald. Ook moet er ieder jaar opnieuw alles ingevuld worden. Vorig jaar heb ik de output in xls kunnen exporteren en vervolgens geordend en terug in een datebase gestopt. Met een zoekfunctie kon men dan de gegevens opzoeken. Het nadeel was dat je ieder kind apart moest opzoeken. Dus als een ouder met 3 kinderen aan kwam lopen, moesten ze alle 3 apart opgezocht worden. wat dan weer de nodige vertraging oplevert.
nu was mijn idee om een account te maken, dat de ouder zelf hun gegevens kunnen invullen, hun kind(eren) daaronder toevoegen en dan bij wijze van spreken met 1 druk op de knop hun kind kunnen inschrijven. Bij de kassa kunnen ze vervolgen zoeken op de naam, en zien dan het volledige overzicht. Het kind of kinderen wordt aanwezig gemeld en gedurende de dag beschikken wij over een aanwezigheidslijst. Op dit moment organiseren we dat maar 1 keer in het jaar. maar misschien is het inderdaad niet verkeerd om er nu al rekening mee te houden dat het er ook meerdere kunnen zijn.
Gewijzigd op 11/04/2015 16:20:15 door marlon vos
Voor de betalingen zou ik zeker een aparte tabel maken. Gescheiden ouders willen misschien beiden de helft overmaken om maar een stom voorbeeld te noemen waardoor je met twee betalingen komt te zitten. Hou daar rekening mee.
Verder denk ik nog aan groepen. Ik weet bijna zeker dat de kinderen in een groep ingedeeld worden maar ik weet niet hoe jullie die groepen samenstellen. Waarschijnlijk is het het beste om per event de mogelijkheid te bieden om de kinderen in een groep te plaatsen.
De kinderen zijn inderdaad tot max 12 jaar. Voor de vrijwilligers hebben we niet echt een aanmelding. Maar zeker iets om over na te denken. is het niet nu, dan wel in de toekomst. Mailing gaat nu nog via mailchimp, maar ook dit is een mooi voorbeeld om te combineren. Op dit moment is het zo dat de kinderen hun eigen vrijwilliger kiezen. Daarna lopen we de verdeling langs en schuiven met de kinderen om de groepen enigszins gelijk te krijgen. Verder doen we er eigenlijk niks mee. Maar wat een geweldig idee om de kinderen/groepen/vrijwilligers te koppelen. Mocht er ooit een vraag/klacht zijn kun je ook de verantwoordelijke teamleider achterhalen. Zit alleen dan even te denken over de opzet. Want ook hier kun je weer heel ver in gaan.
tabellen:
users
-user_id
-username
-...
roles
-role_id
-description
users_roles /* koppeltabel */
user_id
role_id
childeren
-child_id
-parent_user_id
-born
-name
-...
events
-event_id
-when
-description
applications /* aanmeldingen */
-child_id
-event_id
-leader_id /* user_id teamleider */
(-when)
invoices
-invoice_id
-user_id
-datum
-description
-amount
payments
-invoice_id
-datum
-amount
-paymethod
Toevoeging op 12/04/2015 13:15:14:
Met name leader_id in applications is nog wel erg beperkt. slechts alleen één leider per groep.
Als je meerdere leiders per groep wilt kunnen toewijzen is het natuurlijk niet genoeg
Gewijzigd op 12/04/2015 13:04:31 door Frank Nietbelangrijk