[MySQL] settings opslaan in database

[nota]

Ik wil graag bepaalde website-settings opslaan in mijn database. Het gaat hierbij niet om gebruikers-speficieke settings om een aantal instellingen die één maal vastgelegd kunnen worden (bijvoorbeeld het emailadres waar input van het contactformulier terecht moet komen). Ik zit dan ook te denken aan de een enkele settings tabel waarin records vastgelegd kunnen worden met een unieke key en een waarde (bijvoorbeeld in het geval van het emailadres tbv het contactformulier: id=1, waarde=[e-mail]. Is dit een handige manier, of zijn er betere oplossingen?

[Cartman!]

Ik gebruik daar een .ini file voor, makkelijk te editten en het bespaart je weer een query

[nota]

Ja daar zat ik eerst ook aan te denken, maar het moet eigenlijk door de admin via de website aangepast kunnen worden.

[CodeCaster]

Dat kan met een bestandje net zo goed als in de DB.

[nota]

CodeCaster schreef op zondag 17 januari 2010 @ 22:06:
Dat kan met een bestandje net zo goed als in de DB.

ja, nu weet ik wel hoe ik records in een database kan updaten maar hoe kun je het beste zo'n bestand updaten met PHP? Is dat niet een hoop meer code?

[donquix]

Gewoon lekker MySQL gebruiken gezien je aangeeft hier al mee te kunnen werken. Ik zou dan alleen wel een extra kolom toevoegen: "instelling". Dan krijg je bijvoorbeeld: id=1, instelling=email_contact_pagina, waarde=[e-mail]. Zo wordt het geheel wat overzichtelijker en hoef je niet steeds de id's te onthouden.

[Verwijderd]

Kijk eens naar de DBA functies, het stelt weinig voor om daarmee een bestandje met simpele instellingen (zoals een .ini) te schrijven.

[Mike2k]

of een XML...
XML is met php echt een eitje...

http://php.net/manual/en/book.simplexml.php

[Cartman!]

nota schreef op zondag 17 januari 2010 @ 22:09:
[...]


ja, nu weet ik wel hoe ik records in een database kan updaten maar hoe kun je het beste zo'n bestand updaten met PHP? Is dat niet een hoop meer code?

In de TS zei je er niet bij dat het editbaar moest zijn voor een ander in een CMS, vermeld voortaan zo volledig mogelijk wat je wilt. Ik zou het lekker in een config tabel doen en het cachen naar een tekstbestand. Bij een aanpassing weer updaten.

[Gomez12]

Simpele vraag, als je settings in je db staan, waar staan dan je db-settings?

Persoonlijk gaat mijn voorkeur toch uit naar ini bestandjes voor de echte instellingen ( db-settings / mailserver settings / file settings etc )

Settings als contactemailadres etc zou je wel weer in de dbase kunnen zetten, maar gebruik dan aub een normale schrijfwijze ( key / value bijv ) zodat mensen ook kunnen zien wat het is ipv foutgevoelige dingen als numerieke id's die een betekenis hebben...

[CyBeR]

Gomez12 schreef op zondag 17 januari 2010 @ 23:50:
Simpele vraag, als je settings in je db staan, waar staan dan je db-settings?

Ligt aan je applicatie. Wij proppen dat in de apache vhost als een environment variable. De rest staat in mysql.

Persoonlijk gaat mijn voorkeur toch uit naar ini bestandjes voor de echte instellingen ( db-settings / mailserver settings / file settings etc )

Nadeel is dat mensen zonder file-access op je servers dat dan niet aan kunnen passen.

[Gomez12]

CyBeR schreef op zondag 17 januari 2010 @ 23:53:
[...]
Ligt aan je applicatie. Wij proppen dat in de apache vhost als een environment variable. De rest staat in mysql.

Nee, daar kunnen gemiddelde mensen makkelijk bij

[...]
Nadeel is dat mensen zonder file-access op je servers dat dan niet aan kunnen passen.

Tja, deels denk ik als je geen file-access hebt dan heb je ook niets in de serversettings te zoeken.
Maar als je het echt zou willen, het is niet echt rocket-science om 1 pagina te bouwen die het bestandje uitleest en de content in een textbox dumpt en daarna de inhoud van textbox weer wegschrijft in het bestand.

Maar ik ga te veel uit van server settings heb ik het idee, TS wil echt app settings opslaan, die zou ik wel altijd in dbase zetten ( enkel dan zoals ik al eerder zei wel in een normaal leesbaar formaat en niet mysterieuze numerieke codes )

[Verwijderd]

CyBeR schreef op zondag 17 januari 2010 @ 23:53:

Nadeel is dat mensen zonder file-access op je servers dat dan niet aan kunnen passen.

Dat kunnen users zonder write rechten op die database tabel ook niet.

[CyBeR]

Gomez12 schreef op maandag 18 januari 2010 @ 00:11:
[...]

Nee, daar kunnen gemiddelde mensen makkelijk bij

Dat hoeft ook niet

Tja, deels denk ik als je geen file-access hebt dan heb je ook niets in de serversettings te zoeken.

Dat ligt aan je organisatie. De ontwikkelaars bij ons kunnen niet op alle servers rondkutten, bijvoorbeeld.

Maar als je het echt zou willen, het is niet echt rocket-science om 1 pagina te bouwen die het bestandje uitleest en de content in een textbox dumpt en daarna de inhoud van textbox weer wegschrijft in het bestand.

Waarna je feitelijk je eigen databaseje geimplementeerd hebt, maar dan slechter . Dan is in mysql proppen veel makkelijker.

Maar ik ga te veel uit van server settings heb ik het idee, TS wil echt app settings opslaan, die zou ik wel altijd in dbase zetten ( enkel dan zoals ik al eerder zei wel in een normaal leesbaar formaat en niet mysterieuze numerieke codes )

IMO zijn er weinig 'server' settings behalve dan de mysql dsn mischien, en eventueel wat ip-adressen van memcacheds en dergelijke. De rest mag wat mij betreft door admingebruikers aan te passen zijn.

Cheatah: het idee is natuurlijk dat je applicatie die gegevens ontsluit en dan het bewerken ervan kan controleren.

[ Voor 4% gewijzigd door CyBeR op 18-01-2010 00:17 ]

[sanzut]

Ik gebruik daar gewoon een config-tabel voor.

DESC `configuratie` geeft

code:

Array
(
    [Field] => naam
    [Type] => varchar(255)
    [Null] => NO
    [Key] => PRI
    [Default] => 
    [Extra] => 
)
Array
(
    [Field] => waarde
    [Type] => varchar(255)
    [Null] => NO
    [Key] => 
    [Default] => 
    [Extra] => 
)

[Gomez12]

CyBeR schreef op maandag 18 januari 2010 @ 00:17:
[...]
Dat hoeft ook niet

Wel als ik de TS volg, dan moeten blijkbaar alle settings te veranderen zijn...

[...]
Waarna je feitelijk je eigen databaseje geimplementeerd hebt, maar dan slechter . Dan is in mysql proppen veel makkelijker.

Tja, ik weet niet hoor...

Ik vind een .ini / .txt bestandje met ruimte voor commentaar / oude settings etc. een stuk makkelijker dan een db, maarja dat zal ik wel zijn...
We hebben het toch wel over de eenmalige instellingen die enkel en alleen veranderd worden bij installatie / verplaatsing ( andere server ed ), tuurlijk kan je daar allerlei mooie config-pagina's voor maken om het in de dbase te beheren met helpteksten die via ajax in te laden zijn ed. Maar waarom zou je?
Aan de db zelf heb je weinig ( helemaal op de manier van de TS, dan heb je 3 emailadressen met 3 numerieke id's, welke moet je nou veranderen ) want je mist de uitgebreide help etc.
Je moet het altijd via de officiele config-pagina's doen, werken die niet om reden x/y/z dan wordt het gewoon gokwerk.
Wil je er een extra notitie bijzetten als in : deze server is even als nood ertussen gedouwd en wordt over 2 maanden vervangen. Dan moet je of notitie velden erbij aanbrengen of je kunt je notities niet kwijt.

Nee, geef mij maar gewoon ini files waar ik op filesystem nivo kan greppen naar welke apps allemaal de mailserver gebruiken die volgende week vervangen gaat worden.

[...]
IMO zijn er weinig 'server' settings behalve dan de mysql dsn mischien, en eventueel wat ip-adressen van memcacheds en dergelijke. De rest mag wat mij betreft door admingebruikers aan te passen zijn.

Mail servers / image servers / speciale app server ip-adressen / locaties waar hulpprogs staan / locatie waar de app zelf staat...

[CyBeR]

Gomez12 schreef op maandag 18 januari 2010 @ 00:39:
[...]

Wel als ik de TS volg, dan moeten blijkbaar alle settings te veranderen zijn...

Mja, maar uiteindelijk is de locatie van de database er eentje die eigenlijk toch alleen door iemand met file access veranderd kan worden (d'r moet tenslotte ook een db worden aangemaakt, met data, etc.) zodat die ene setting wel een uitzondering kan krijgen. 't is ook meteen een beetje een bootstrap-idee. En door 'm dan aan je http daemon mee te geven ipv in een file te proppen scheelt dat je weer een file die geparset moet worden bij elke request. En ja, op veel requests maakt dat uit voor je performance.

Ik vind een .ini / .txt bestandje met ruimte voor commentaar / oude settings etc. een stuk makkelijker dan een db, maarja dat zal ik wel zijn...
We hebben het toch wel over de eenmalige instellingen die enkel en alleen veranderd worden bij installatie / verplaatsing ( andere server ed ), tuurlijk kan je daar allerlei mooie config-pagina's voor maken om het in de dbase te beheren met helpteksten die via ajax in te laden zijn ed. Maar waarom zou je?

Nee. We hadden 't ook over een emailadres van een contactformulier. Dat soort dingen zijn bij uitstek settings die elke zoveel tijd door een leek veranderd moeten kunnen worden. En dat je 't in een db propt betekent niet dat je de mogelijkheid tot commentaar en versioning e.d. kwijt bent.

Mail servers / image servers / speciale app server ip-adressen / locaties waar hulpprogs staan / locatie waar de app zelf staat...

Kan prima in een db zodat een applicatieadmin ze kan veranderen zonder meteen root nodig te hebben.

[ Voor 3% gewijzigd door CyBeR op 18-01-2010 01:04 ]

[Gomez12]

CyBeR schreef op maandag 18 januari 2010 @ 01:03:
[...]
En door 'm dan aan je http daemon mee te geven ipv in een file te proppen scheelt dat je weer een file die geparset moet worden bij elke request. En ja, op veel requests maakt dat uit voor je performance.

Interessant, nooit geweten. Maar scheelt het doorgeven via http-daemon relatief veel of is het echt een micro-optimalisatie die ergens aan het einde van de lijst micro-optimalisaties staat?
Ik kan me namelijk zo indenken dat de http-daemon niet voor dit soort grappen geoptimaliseerd is, waar een scripting taal toch wel redelijk geoptimaliseerd is.

[...]
Nee. We hadden 't ook over een emailadres van een contactformulier. Dat soort dingen zijn bij uitstek settings die elke zoveel tijd door een leek veranderd moeten kunnen worden. En dat je 't in een db propt betekent niet dat je de mogelijkheid tot commentaar en versioning e.d. kwijt bent.

Zei ik eerder al, ik bekijk het meer vanuit algemene eenmalige settings.
E-mail adres voor een contactformulier is imho zelfs een twijfelachtige app-setting, als je later een 2e contactformulier wilt hebben ( bijv voor verkoop-vragen ) dan wil ik niet weer die eenmalige settings induiken
Dan liever gewoon een setting per contactformulier.

Commentaar en versioning zie ik niet echt vaak in db's terugkomen, ja het kan, maar veelal houdt niemand er rekening mee...

[...]
Kan prima in een db zodat een applicatieadmin ze kan veranderen zonder meteen root nodig te hebben.

??? Dacht ik het eindelijk eens redelijk met je eens te zijn, kom jij aan met een root-eis om 1 config-filetje te kunnen veranderen???
Ik hoop dat je toch wel weet dat je best applicatieadmins ook op FS nivo enkel toegang kan geven tot hun applicaties???

[CyBeR]

Gomez12 schreef op maandag 18 januari 2010 @ 01:31:
[...]

??? Dacht ik het eindelijk eens redelijk met je eens te zijn, kom jij aan met een root-eis om 1 config-filetje te kunnen veranderen???
Ik hoop dat je toch wel weet dat je best applicatieadmins ook op FS nivo enkel toegang kan geven tot hun applicaties???

Ik wil ze überhaupt niet op m'n servers

[nota]

Gomez12 schreef op maandag 18 januari 2010 @ 00:39:

Ik vind een .ini / .txt bestandje met ruimte voor commentaar / oude settings etc. een stuk makkelijker dan een db, maarja dat zal ik wel zijn...

Dat is het in principe denk ik ook, maar de personen die het aan moeten passen zijn redelijke digibeten (schuttersgilde met voornamelijk overjarige individuen). Waarschijnlijk loopt het al helemaal fout als ik er een opmerkingenveld bij zet of de historie bij ga houden. Ben geen ICT'er en het programmeren van het contactformulier, de emailsetting en een via de user interface invulbare tabel met naw gegevens van het bestuur die af worden gebeeld bij het contactformulier heeft me 4 uur gekost, het moet natuurlijk wel leuk blijven

[Gomez12]

CyBeR schreef op maandag 18 januari 2010 @ 02:39:
[...]


Ik wil ze überhaupt niet op m'n servers

Firewall blocks op ip-niveau gevoed door inlogs vanaf de applicatie werken erg goed heb ik wel eens gemerkt

Tip is wel om je telefoon uit te zetten...

nota schreef op dinsdag 19 januari 2010 @ 00:09:
[...]
Dat is het in principe denk ik ook, maar de personen die het aan moeten passen zijn redelijke digibeten (schuttersgilde met voornamelijk overjarige individuen). Waarschijnlijk loopt het al helemaal fout als ik er een opmerkingenveld bij zet of de historie bij ga houden. Ben geen ICT'er en het programmeren van het contactformulier, de emailsetting en een via de user interface invulbare tabel met naw gegevens van het bestuur die af worden gebeeld bij het contactformulier heeft me 4 uur gekost, het moet natuurlijk wel leuk blijven

Tja, ik zou dan zeker adviseren om een historie/opmerkingenveld bij te houden, juist digibeten hebben al heel snel de neiging om met de beste bedoelingen van de wereld het verkeerde veld te veranderen...

Simpele vraag : Hoelang denk je dat het duurt voordat iemand doorheeft dat het emailadres niet klopt? En hoeveel mailtjes zijn er daardoor verdwenen?

Persoonlijk zou ik bij een digibeten systeem ( en bij de meeste andere ook ) gewoon de emails naar dbase schrijven en dan via cron de emails vanuit de dbase halen en versturen, dan heb je in ieder geval altijd het origineel...

[nota]

Gomez12 schreef op dinsdag 19 januari 2010 @ 00:19:

Tja, ik zou dan zeker adviseren om een historie/opmerkingenveld bij te houden, juist digibeten hebben al heel snel de neiging om met de beste bedoelingen van de wereld het verkeerde veld te veranderen...

Simpele vraag : Hoelang denk je dat het duurt voordat iemand doorheeft dat het emailadres niet klopt? En hoeveel mailtjes zijn er daardoor verdwenen?

Persoonlijk zou ik bij een digibeten systeem ( en bij de meeste andere ook ) gewoon de emails naar dbase schrijven en dan via cron de emails vanuit de dbase halen en versturen, dan heb je in ieder geval altijd het origineel...

Ik denk dat een opmerkingenveld de gebruiker niet weerhoudt om alsnog een foutief mailadres in te voeren. Ik check wel op validiteit maar niet op juistheid van het emailadres. Het gaat me te ver om eventuele bounces te signaleren. Wat ik wel doe is zoals je al aangeeft het opslaan van de emails in de database, maar het versturen laat ik gewoon gelijktijdig plaatsvinden en niet via een cronjob.

[CyBeR]

Niets houdt een gebruiker tegen om een foutief adres in te voeren. En als 'ie [e-mail] invult ipv [e-mail] dan ga je daar als app ook niets uithalen met input validation. Maar wat je wel vrij simpel onder water kunt doen is een simpele versioning bijhouden, zodat je simpel terug kunt naar hoe de vorige setting was als blijkt dat de nieuwe niet werkt.

[ Voor 14% gewijzigd door CyBeR op 19-01-2010 00:38 ]

[nota]

CyBeR schreef op dinsdag 19 januari 2010 @ 00:37:
Niets houdt een gebruiker tegen om een foutief adres in te voeren. En als 'ie [e-mail] invult ipv [e-mail] dan ga je daar als app ook niets uithalen met input validation. Maar wat je wel vrij simpel onder water kunt doen is een simpele versioning bijhouden, zodat je simpel terug kunt naar hoe de vorige setting was als blijkt dat de nieuwe niet werkt.

maar je merkt het dan toch pas als het al te laat is? En dan kun je net zo snel zelf het juiste emailadres intypen...

[CyBeR]

nota schreef op dinsdag 19 januari 2010 @ 00:39:
[...]


maar je merkt het dan toch pas als het al te laat is? En dan kun je net zo snel zelf het juiste emailadres intypen...

Ja voor een e-mailadres wel, maar ik dacht dat we dit ook op andere settings gingen toepassen?

[Hydra]

CodeCaster schreef op zondag 17 januari 2010 @ 22:06:
Dat kan met een bestandje net zo goed als in de DB.

Stop dan lekker je hele site in een 'bestandje'.