CronJob-Service
bei SELFPHP mit ...
|
+ minütlichen Aufrufen
+ eigenem Crontab Eintrag
+ unbegrenzten CronJobs
+ Statistiken
+ Beispielaufrufen
+ Control-Bereich
Führen Sie mit den CronJobs von
SELFPHP zeitgesteuert Programme
auf Ihrem Server
aus. Weitere Infos
|
:: Anbieterverzeichnis ::
Globale Branchen
Informieren Sie sich über ausgewählte Unternehmen im Anbieterverzeichnis von SELFPHP
:: Newsletter ::
Abonnieren Sie hier den kostenlosen
SELFPHP Newsletter!
|
MySQLi/PDO/(MySQL) Anfänger, Fortgeschrittene oder Experten können hier Fragen und Probleme rund um MySQLi/PDO/(MySQL) diskutieren |
02.12.2010, 11:09:08
|
Junior Member
|
|
Registriert seit: May 2003
Ort: Trier
Alter: 47
Beiträge: 310
|
|
Normalisierung
Hi Com,
in einem meiner Projekte sollen die Admins die Möglichkeit haben auch ihre Telefon-, Telefax-, Handynummer und E-Mail-Adressen jeweils die Privaten als auch die Beruflichen/Dienstlichen eintragen zu können. Das hat was mit dem Impressum zu tun.
Um der Normalisierung (ist glaube ich die 5 Normalform) gerecht zu werden und nicht die maximale Anzahl der jeweiligen Einträge zu beschneiden sondern die Entscheidung dem jeweiligen Admin zu überlassen, hatte ich ursprünglich für jeden Kontakt-Daten-Typ (Telefon, Fax, Handy, E-Mail) zwei Tabellen angelegt, jeweils eine für den Privaten und eine für den Beruflichen/Dienstlichen Daten-Typ.
Irgendwann hatte ich dann die Idee, man könnte doch Tabellen sparen wenn man die sachen zusammenfasst und durch ein weiteres Tabellenfeld eine Untercheidung trifft. So habe ich jetzt eine Tabelle für z.B. Telefonnummern, und auch die anderen Kontakt-Daten-Typen, und darin ein Feld "type". Dieses Feld ist ein enum-Feld mit den Werten "private" und "business".
Meine Frage an die Datenbank-Profis.
Was erachtet Ihr als Besser/Vorteilhafter? Getrennte Tabellen nach Privat und Beruflich/Dienstlich oder zusammengefasst mit Unterscheidungsfeld?
Hoffe auf eine rege und fruchtbare Diskussion, und vielleicht auch noch einige Denkanstöße.
Kai aka Knight1
|
02.12.2010, 11:19:06
|
SELFPHP Experte
|
|
Registriert seit: Jun 2008
Alter: 15
Beiträge: 2.269
|
|
AW: Normalisierung
Zitat:
oder zusammengefasst mit Unterscheidungsfeld?
|
Meines Erachtens brauchst du 2 unterscheidungen
Teltabelle:
id | priv/gesch | tel/fax | nummer
Oder evtl noch besser:
Nummerntype:
id | Type
1 | Telefon geschäftlich
2 | Mobil geschäftlich
3 | Fax geschäftlich
4 | Telefon privat
usw.
Teltabelle:
id | type_id | nummer
|
02.12.2010, 11:28:16
|
Junior Member
|
|
Registriert seit: Aug 2010
Alter: 14
Beiträge: 395
|
|
AW: Normalisierung
Zitat:
Zitat von knight1
Um der Normalisierung (ist glaube ich die 5 Normalform) gerecht zu werden
|
Es gibt zwar fünf Normalformen, aber für gewöhnlich werden Tabellen nur bis zur dritten Normalform definiert. Alles weitere geht unheimlich auf die Performance, da sehr viele Tabellen entstehen.
Zitat:
Zitat von DokuLeseHemmung
Nummerntype:
id | Type
1 | Telefon geschäftlich
2 | Mobil geschäftlich
3 | Fax geschäftlich
4 | Telefon privat
usw.
Teltabelle:
id | type_id | nummer
|
Wäre auch mein Vorschlag gewesen.
Grüße
Thomas
__________________
Die SQL-Backstube
Bietet Rezepte, Lösungen und ausführliche Beispiele rund um gesundes SQL und zufriedene Datenbanken.
|
02.12.2010, 11:49:12
|
Junior Member
|
|
Registriert seit: May 2003
Ort: Trier
Alter: 47
Beiträge: 310
|
|
AW: Normalisierung
Momentan habe ich es so:
Eine eigene Tabelle für Telefonnummern:
id
country_code
area_code
callingnumber
admin_id
type "private/business"
Eine eigene Tabelle für Telefaxnummern:
id
country_code
area_code
callingnumber
admin_id
type "private/business"
und genauso eine eigene Tabelle für Handynummern mit der selben Struktur.
Bei den E-Mail-Adressen halt anstelle der Nummern ein Feld für die E-Mail-Adresse.
Verstehe ich das richtig dass ich die drei Rufnummertypen auch nochmal zusammenfassen sollte?
Kai aka Knight1
|
02.12.2010, 13:00:45
|
Junior Member
|
|
Registriert seit: Aug 2010
Alter: 14
Beiträge: 395
|
|
AW: Normalisierung
Ein Beispiel dazu ...
Code:
CREATE TABLE verbindung (
id INT NOT NULL,
country_code VARCHAR(10) NOT NULL,
nummer VARCHAR(100) NOT NULL,
admin_id INT NOT NULL,
type_id INT NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE verbindung_type (
id INT NOT NULL,
bezeichnung VARCHAR(50) NOT NULL,
PRIMARY KEY (id)
);
INSERT INTO verbindung VALUES
( 1, 'DE', '098/1212', 1, 1 ),
( 2, 'DE', 'email@hier.de', 1, 2 ),
( 3, 'DE', '098/1212-12', 1, 3 );
INSERT INTO verbindung_type VALUES
( 1, 'Telefon'),
( 2, 'E-Mail'),
( 3, 'Telefax'),
( 4, 'Telefon privat'),
( 5, 'E-Mail privat'),
( 6, 'Telefax privat');
SELECT *
FROM verbindung v
JOIN verbindung_type vt
ON vt.id = v.type_id
ORDER BY v.id;
+----+--------------+---------------+----------+---------+----+-------------+
| id | country_code | nummer | admin_id | type_id | id | bezeichnung |
+----+--------------+---------------+----------+---------+----+-------------+
| 1 | DE | 098/1212 | 1 | 1 | 1 | Telefon |
| 2 | DE | email@hier.de | 1 | 2 | 2 | E-Mail |
| 3 | DE | 098/1212-12 | 1 | 3 | 3 | Telefax |
+----+--------------+---------------+----------+---------+----+-------------+
3 rows in set (0.00 sec)
mysql>
Grüße
Thomas
__________________
Die SQL-Backstube
Bietet Rezepte, Lösungen und ausführliche Beispiele rund um gesundes SQL und zufriedene Datenbanken.
|
02.12.2010, 13:32:36
|
Junior Member
|
|
Registriert seit: May 2003
Ort: Trier
Alter: 47
Beiträge: 310
|
|
AW: Normalisierung
Zitat:
Zitat von thomas_w
Ein Beispiel dazu ...
Code:
CREATE TABLE verbindung (
id INT NOT NULL,
country_code VARCHAR(10) NOT NULL,
nummer VARCHAR(100) NOT NULL,
admin_id INT NOT NULL,
type_id INT NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE verbindung_type (
id INT NOT NULL,
bezeichnung VARCHAR(50) NOT NULL,
PRIMARY KEY (id)
);
INSERT INTO verbindung VALUES
( 1, 'DE', '098/1212', 1, 1 ),
( 2, 'DE', 'email@hier.de', 1, 2 ),
( 3, 'DE', '098/1212-12', 1, 3 );
INSERT INTO verbindung_type VALUES
( 1, 'Telefon'),
( 2, 'E-Mail'),
( 3, 'Telefax'),
( 4, 'Telefon privat'),
( 5, 'E-Mail privat'),
( 6, 'Telefax privat');
SELECT *
FROM verbindung v
JOIN verbindung_type vt
ON vt.id = v.type_id
ORDER BY v.id;
+----+--------------+---------------+----------+---------+----+-------------+
| id | country_code | nummer | admin_id | type_id | id | bezeichnung |
+----+--------------+---------------+----------+---------+----+-------------+
| 1 | DE | 098/1212 | 1 | 1 | 1 | Telefon |
| 2 | DE | email@hier.de | 1 | 2 | 2 | E-Mail |
| 3 | DE | 098/1212-12 | 1 | 3 | 3 | Telefax |
+----+--------------+---------------+----------+---------+----+-------------+
3 rows in set (0.00 sec)
mysql>
Grüße
Thomas
|
Mir stellt sich da die Frage: Warum eine weitere Tabelle anlegen wenn es doch um's reduzieren von Tabellen geht?
Umso länger ich über den Vorschlag
Zitat:
Zitat von DokuLeseHemmung
Meines Erachtens brauchst du 2 unterscheidungen
Teltabelle:
id | priv/gesch | tel/fax | nummer
...
|
von DokuLeseHemmung nachdenke, umso besser gefällt mir dieser.
Außerdem dürfte doch die Abfrage mit 2 Tabellen, wovon eine den Typ benennt/definiert, langsamer sein, als einfach nur eine einzige Tabelle abzufragen, oder?
Was ich aufjedenfall beibehalten werde, ist die Trennung von Landesvorwahl, Orts-/Netzvorwahl und Rufnummer. Die E-Mail-Adressen lasse ich auch in einer separaten Tabelle.
Kai aka Knight1
|
02.12.2010, 14:36:30
|
Member
|
|
Registriert seit: Nov 2007
Beiträge: 843
|
|
AW: Normalisierung
Hi
"manche" sollten sich davon verabschieden alles mit einem Select abzufrühstücken.
Normalisierung steht gegenüber Performance genauso wie gegenüber deiner Anwendung.
Um "einfach" eine Spalte zu sparen brauchste du vielleicht keine neue Tabelle, aber wenn
60% deiner Daten Spalten nicht füllen macht eine Normalisierung / Auslagerung Sinn.
Wenn aber nur 5% Fax nicht ausfüllen ist es vielleicht nicht sinnvoll.
Stell dir mal vor deine User möchten mehr als eine Telefonnummer aber kein
Fax und wiederum mehrere Emails hinterlegen, dann ist die von Thomas vorgestellte
variante die einzige Lösung.
mfg
CKaos
PS: Es geht bei Normalisierung nicht um Tabellen zu sparen sondern um leere / doppelt belegte Spalten zu verhindern.
__________________
"Wenn die Leute Häuser so bauen würden, wie wir Programme schreiben, würde der erstbeste Specht unsere Zivilisation zerhacken."
In den allermeisten Fällen sitzt der Bug etwa 40 cm vor dem Monitor!
|
02.12.2010, 16:06:44
|
SELFPHP Profi
|
|
Registriert seit: Apr 2008
Alter: 48
Beiträge: 1.938
|
|
AW: Normalisierung
Zitat:
Zitat von knight1
Umso länger ich über den Vorschlag [...] nachdenke, umso besser gefällt mir dieser.
|
lass es und setze die von doku, thomas und ckaos favorisierte lösung ein. denk' mal ein bissel abstrakter und überleg' dir, wie man ein möglichst flexibles und vor allem erweiterbares model konstruiert.
du willst die namen und die anzahl der spalten davon abhängig machen, was für daten (mail-adresse, phone-numer, schlüpper-grösse) du speichern möchtest...? das geht in die falsche richtung.
cx
|
02.12.2010, 19:52:58
|
Junior Member
|
|
Registriert seit: May 2003
Ort: Trier
Alter: 47
Beiträge: 310
|
|
AW: Normalisierung
Habe jetzt ein bischen darüber nachgedacht.
Werde die Tabellenstruktur jeweils getrennt für Telefon-, Telefax- und Handynummer vorerst folgendermaße belassen:
Code:
CREATE TABLE IF NOT EXISTS `TABELLENNAME` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`country_code` int(6) NOT NULL,
`area_code` int(10) NOT NULL,
`call_number` int(10) NOT NULL,
`admin_id` bigint(20) unsigned NOT NULL,
`type` enum('private','business') COLLATE utf8_unicode_ci NOT NULL DEFAULT 'private',
`show_in_frontend` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `admin_id` (`admin_id`),
KEY `type` (`type`),
KEY `show_in_frontend` (`show_in_frontend`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=FIXED AUTO_INCREMENT=1;
und für E-Mails folgende
Code:
CREATE TABLE IF NOT EXISTS `TABELLENNAME` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`address` mediumtext COLLATE utf8_unicode_ci NOT NULL,
`admin_id` bigint(20) unsigned NOT NULL,
`type` enum('private','business') COLLATE utf8_unicode_ci NOT NULL DEFAULT 'private',
`newsletter` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`contact_form` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`guestbook_notification` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`show_in_frontend` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`settings_change_notification` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`private_messages-notify_on_first_read` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`private_messages-notify_on_new_message` enum('0','1') COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `newsletter` (`newsletter`),
KEY `contact_form` (`contact_form`),
KEY `admin_id` (`admin_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=DYNAMIC AUTO_INCREMENT=1;
Werde mir aber noch weiter Gedanken machen.
Kai aka Knight1
|
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
|
|
Forumregeln
|
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
HTML-Code ist aus.
|
|
|
Alle Zeitangaben in WEZ +2. Es ist jetzt 00:45:19 Uhr.
|