Huidige datum in database
Hoe kan ik het voor elkaar krijgen dat als ik niks invoer het ook leeg blijft in de database?
Dit is het script.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
//Check which start/end date to use. Will be determined by recurring events addon, if installed.
if (array_key_exists('recurrence_start_date', $recurrence_arr)) {
//Recurring event
$start_date = $recurrence_arr['recurrence_start_date'];
} elseif ( !empty($_REQUEST['start_date']) && !empty($_REQUEST['recurrence_start_date']) ) {
//If they leave the Event Start Date empty, the First Event Date in the recurrence module is selected
$start_date = sanitize_text_field($_REQUEST['recurrence_start_date']);
} elseif ( isset($_POST['recurrence']) && $_POST['recurrence'] == 'Y' && !empty($_REQUEST['start_date']) ) {
$start_date = sanitize_text_field($_REQUEST['recurrence_manual_dates'][0]);
} else {
$start_date = !empty($_REQUEST['start_date']) ? sanitize_text_field($_REQUEST['start_date']) : date('Y-m-d',time());
}
?>
//Check which start/end date to use. Will be determined by recurring events addon, if installed.
if (array_key_exists('recurrence_start_date', $recurrence_arr)) {
//Recurring event
$start_date = $recurrence_arr['recurrence_start_date'];
} elseif ( !empty($_REQUEST['start_date']) && !empty($_REQUEST['recurrence_start_date']) ) {
//If they leave the Event Start Date empty, the First Event Date in the recurrence module is selected
$start_date = sanitize_text_field($_REQUEST['recurrence_start_date']);
} elseif ( isset($_POST['recurrence']) && $_POST['recurrence'] == 'Y' && !empty($_REQUEST['start_date']) ) {
$start_date = sanitize_text_field($_REQUEST['recurrence_manual_dates'][0]);
} else {
$start_date = !empty($_REQUEST['start_date']) ? sanitize_text_field($_REQUEST['start_date']) : date('Y-m-d',time());
}
?>
Graag volgende keren je scripts tussen <?php ?> zetten (of tussen [code][/code])[/modedit]
Gewijzigd op 29/04/2013 19:15:04 door Nick Dijkstra
Kijk eens goed naar regel 12...
Mysql staat '0000-00-00' (of gewoon 0) toe, dus gebruik dat als default in je create table voor de kolom start_date. Op het moment dat je de insert query genereert sla je de start_date kolom over, zowel als in de kolomlijst als in de values.
Ger van Steenderen op 29/04/2013 21:49:12:
In een goed genormaliseerde database zijn er geen nullable kolommen.
Volgens de officiële beschrijving van de eerste normaalvorm zou deze uitspraak waar zijn. Ted Codd, degene die de eerste normaalvorm heeft beschreven, is daar echter allang op teruggekomen, want zelfs in een genormaliseerde database zijn null-waardes te verdedigen. Alleen in de primary key mag/kun je nooit null-waardes gebruiken.
Sinds 1985 of zo onderscheidt Codd zelfs twee soorten null-waardes: niet bekend en niet van toepassing.
Voorbeeld: je slaat in je database een naam op in de velden Voornaam, Tussenvoegsel en Achternaam. Voor iemand die "Willem van Oranje" heet, gaat dat goed. Maar wat doe je als iemand "Sjaak Swart" heet? Je zou het tussenvoegsel kunnen opslaan als lege string, maar strikt genomen klopt dat niet.
Ander voorbeeld: je slaat in je database het adres van je werknemers op in de velden Straatnaam en Huisnummer. Maar wat nu als je zijn huisnummer niet weet, of als hij in een straat woont zonder huisnummers? (en dat laatste komt voor, zelfs in Nederland ;-) )
Of, misschien iets wat vaker voorkomt: je hebt velden voor een vast en een mobiel telefoonnummer. Maar als iemand alleen een vast (of alleen een mobiel) nummer heeft?
Je zou natuurlijk een aparte tabel kunnen aanmaken voor telefoonnummers. Maar je zou dan ook een tabel kunnen aanmaken met straatnamen en een tabel met huisnummers. Waar trek je de grens? Je moet niet gaan overnormaliseren, want dan wordt je database volkomen onwerkbaar. Normalisatie is een middel en geen doel.
In de praktijk zie je zelfs dat bepaalde databases worden gedenormaliseerd om bijvoorbeeld de performance te verbeteren of de complexiteit te verminderen.
Gewijzigd op 29/04/2013 23:07:43 door Willem vp
Willem vp op 29/04/2013 20:23:53:
Kijk eens goed naar regel 12...
Ik had al het vermoeden dat het in deze regel was, omdat ik al een aantal poginen had geprobeerd wat naar deze regel leidde.
In ieder geval bedankt voor de tip. Dit is het oplossing.
Quote:
//Check which start/end date to use. Will be determined by recurring events addon, if installed.
if (array_key_exists('recurrence_start_date', $recurrence_arr)) {
//Recurring event
$start_date = $recurrence_arr['recurrence_start_date'];
} elseif ( !empty($_REQUEST['start_date']) && !empty($_REQUEST['recurrence_start_date']) ) {
//If they leave the Event Start Date empty, the First Event Date in the recurrence module is selected
$start_date = sanitize_text_field($_REQUEST['recurrence_start_date']);
} elseif ( isset($_POST['recurrence']) && $_POST['recurrence'] == 'Y' && !empty($_REQUEST['start_date']) ) {
$start_date = sanitize_text_field($_REQUEST['recurrence_manual_dates'][0]);
} else {
$start_date = ($_REQUEST['start_date']);
}
if (array_key_exists('recurrence_start_date', $recurrence_arr)) {
//Recurring event
$start_date = $recurrence_arr['recurrence_start_date'];
} elseif ( !empty($_REQUEST['start_date']) && !empty($_REQUEST['recurrence_start_date']) ) {
//If they leave the Event Start Date empty, the First Event Date in the recurrence module is selected
$start_date = sanitize_text_field($_REQUEST['recurrence_start_date']);
} elseif ( isset($_POST['recurrence']) && $_POST['recurrence'] == 'Y' && !empty($_REQUEST['start_date']) ) {
$start_date = sanitize_text_field($_REQUEST['recurrence_manual_dates'][0]);
} else {
$start_date = ($_REQUEST['start_date']);
}
Ik ben het met je eens dat normaliseren een middel is en geen doel.
Maar als jij mij kan uitleggen hoe (My)SQL het onderscheid kan maken tussen onbekend en nvt bij geen waarde, hou ik me zeer aanbevolen.
Naar mijn idee, zal dan toch een bepaalde waarde toegekend moeten worden.
Denormaliseren vanwege de complexiteit vind ik geen argument, meestal wordt de db daar minder complex van.
De zesde normaalvorm is heel eenduidig (allemaal 1-1 relaties en tabellen met maar 2 kolommen).
Performance sucks natuurlijk, dus dat ook alleen maar waar absoluut nodig (zelden).
Imo (in tegen stelling tot de algemene tendens) staat daar waar mogelijk de db minimaal in BCNF, wat als gevolg heeft dat ze meestal ook 5NF bereiken.