Heute geht es einmal etwas theoretischer zu. Das Thema dieses Artikels sollen Feldlängen von Datenbankfeldern für Adressen sein. Bei jeder zweiten Datenbank die ich anlege, stehe ich vor dem selben Problem: Wie lang/groß mache ich eigentlich die Datenbankfelder für Adressen? Also Felder wie Vorname, Nachname, Straße, E-Mail-Adresse, etc. Bisher habe ich mich entweder an gegebenen Anforderungen oder alten Datenbanken orientiert. Doch nun wollte ich das Thema ein für alle mal richtig aufarbeiten. Die Frage lautet also: Gibt es eigentlich einen Standard für Adressfeld-Längen?
Auf der Suche nach Standards für Adressfeldlängen
Eine Suche nach “Adresse Feldlängen für Datenbanken” spuckt etliche Treffer aus. Leider findet man überall nur Meinungen und Erfahrungen. So werden auf Wikibooks andere Längen angegeben als in einschlägigen Foren. Und in Fachbüchern gibt auch jeder Autor eine andere Empfehlung. Nach einiger Recherche bin ich dann auf den Government Data Standards Catalogue gestoßen, der dem britischen e-Government Interoperability Framework (e-GIF) entspringt.
Da dieses Dokument jedoch zum einen schon etwas älter ist und zum anderen keine Rücksicht auf ggf. existierende deutsche Eigenheiten nimmt, habe ich nach einer weiteren Quelle gesucht. Dabei habe ich mir die SAP Standardtabellen ADRC, T005T, ADR06 und LFA1 vorgenommen, da ich davon ausgehe, dass bei der Anzahl der Kunden, die die SAP hat, ausreichend Erfahrungswerte zur korrekten Dimensionierung der Felder vorliegen. Die Tabelle folgende Tabelle zeigt Werte, die ich aus den beiden Quellen entnommen habe.
| E-GIF | SAP (ADRC, T005T, ADR06) | SAP (LFA1) | |
| Vorname | 35 | 40 | 1-2 Zeilen á 35 |
| Nachname | 35 | 40 | 1-2 Zeilen á 35 |
| Straße | 2-5 Zeilen á 35 | 60 | 35 |
| Hausnummer | 10 | ||
| Postleitzahl | 10 | 10 | |
| Stadt | 40 | 35 | |
| Land | 50 | 3 (als Länderschlüssel) | |
| E-Mail-Adresse | 255 | 241 | n/a |
| Telefonnummer | 12 | (30+10) | 16 |
Wie die Tabelle zeigt, geht die SAP teils etwas großzügiger (wenn bedauernswerter Weise auch inkonsequenter) mit den Feldlängen um. Die “Wahrheit” wird wohl irgendwo dazwischen liegen. Da ich auch dieses mal keinen “richtigen” / offiziellen Standard bzw. Norm finden konnte, werde ich mich für das nächste Projekt erst mal an den Werten aus der oben stehenden Tabelle orientieren.
Solltet ihr einen offiziellen Standard kennen, würde ich mich freuen, wenn ihr den Namen bzw. einen Link dazu in den Kommentaren hinterlassen würdet.
Damit kannst du deinen Feldern ausreichend Platz einräumen und musst dir keine Gedanken über die maximale Länge machen.
This is getting a bit more subjective, but I much prefer the Zune Marketplace. The interface is colorful, has more flair, and some cool features like ‘Mixview’ that let you quickly see related albums, songs, or other users related to what you’re listening to. Clicking on one of those will center on that item, and another set of “neighbors” will come into view, allowing you to navigate around exploring by similar artists, songs, or users. Speaking of users, the Zune “Social” is also great fun, letting you find others with shared tastes and becoming friends with them. You then can listen to a playlist created based on an amalgamation of what all your friends are listening to, which is also enjoyable. Those concerned with privacy will be relieved to know you can prevent the public from seeing your personal listening habits if you so choose.
Damit kannst du deinen Feldern ausreichend Platz einräumen und musst dir keine Gedanken über die maximale Länge machen.
Falls du mit Datenbanken wie Mysql arbeitest, ist die Antwort ganz einfach: varchar. Im Gegensatz zu char wird nur so viel Speicher belegt, wie auch benötigt wird. Damit kannst du deinen Feldern ausreichend Platz einräumen und musst dir keine Gedanken über die maximale Länge machen.