Apa praktik terbaik yang paling umum pada panjang dan tipe data pada bidang umum seperti:
dll ....
Jawaban:
Saya cenderung sangat curiga terhadap serangkaian praktik terbaik universal karena, untuk sebagian besar bidang ini, iblis ada dalam rinciannya. Hanya karena informasinya relatif umum tidak berarti aplikasi Anda menggunakan data dengan cara yang persis sama dengan aplikasi lain yang menggunakannya. Itu berarti model data Anda mungkin harus sedikit berbeda.
STATEtabel dan membuat hubungan kunci asing antara STATEdan ADDRESStabel. Tetapi kemampuan untuk mengidentifikasi nilai-nilai yang valid menyiratkan bahwa Anda membatasi sekumpulan alamat yang valid setidaknya untuk satu set negara tertentu. Itu bagus untuk banyak situs, tetapi kemudian Anda harus melakukan sedikit pekerjaan untuk mendukung negara baru.CITYtabel dengan kota yang valid dan hubungan kunci asing antara CITYdan ADDRESStabel. Di sisi lain, jika Anda hanya mencoba untuk mendapatkan produk yang dikirim dan Anda tidak terlalu peduli jika Anda memiliki berbagai versi dari kota yang sama di meja Anda, membiarkan pengguna memasukkan bentuk bebas teks sudah cukup. Tentu saja, jika Anda menyimpan kunci asing, Anda akan memiliki cukup banyak pekerjaan untuk memastikan bahwa Anda memiliki semua nilai yang valid. Tetapi ada produk di mana intinya adalah bahwa perusahaan telah melakukan pekerjaan itu (yaitu database pajak penjualan).Anda mungkin juga menebak berdasarkan data sampel dan pemirsa yang diharapkan. Itu tergantung pada lokasi Anda.
Beberapa catatan:
Alamat:
Nama:
Nomor telepon: Kode internasional, panjang, seluler vs rumah, bolehkan hanya seluler sebagai nomor
Selain jawaban hebat di atas, jangan lupa untuk menerima karakter unikode. Hanya karena Anda berada di AS tidak berarti Anda tidak ingin menerima karakter asing ke dalam kolom Anda.
Yang mengatakan, saya biasanya merekomendasikan 50 karakter untuk nama. 320 harus lebih dari cukup untuk alamat email (Anda dapat memeriksa standar ANSI untuk memastikan). Untuk kesalahan alamat di sisi hati-hati dengan 255 karakter. Meskipun Anda mungkin tidak akan pernah membutuhkan alamat sebesar itu, Anda mungkin bisa jika Anda menyertakan garis C / O dan hal-hal seperti itu. Kota harus cukup besar, ada beberapa nama kota yang cukup panjang di luar sana. Untuk negara pergi dengan tabel anak, sama dengan negara. Untuk kode pos jangan lupa tentang kode pos internasional yang lebih panjang dari kode pos AS. Hanya karena Anda tidak mendukung internasional, Anda masih mungkin. Ada banyak warga AS yang tinggal di berbagai negara termasuk orang-orang militer.
Jangan lupa bahwa negara harus opsional karena banyak negara tidak memiliki negara.
Pantat saya semakin sakit karena duduk di pagar, jadi saya akan hanya membuang beberapa jawaban dan berharap untuk tidak turun ke pemungutan suara terlupakan. Tolong tawarkan kritik yang membangun.
min: 6 (a@g.cn). Atau 3 jika Anda ingin melacak alamat email domain lokal
maks: 320 254 (RFC)
Jumlah kode untuk memvalidasi email sebenarnya gila, jadi anggap saja valid jika memiliki "@"
Anda mungkin ingin mengabstraksi alamat email sebagai "metode komunikasi", sehingga Anda dapat dengan mudah mendaftar semua metode yang digunakan untuk berkomunikasi dengan pengguna.
Jenis kelamin dapat berubah seiring waktu, sehingga Anda dapat melacaknya jika penting bagi Anda. Ikuti http://en.wikipedia.org/wiki/ISO/IEC_5218
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);
Saya akan mengambil jalan keluar murah dan tetap berpegang pada alamat Amerika Utara.
Lebih mudah bagi negara-negara abstrak, divisi, kota, dan kabupaten sebagian besar karena perpajakan. Pajak dapat diterapkan di banyak tingkatan, jadi jika Anda dapat menunjukkan tarif pajak pada wilayah geografis yang abstrak, Anda adalah emas.
GeographicArea :
id: int
type: {country, division, county, city, indian reservation}
name: varchar(45) [1]
abbreviation: nullable varchar(4)
parent_id: nullable int
Alamat :
id: int
postal_area_id: int, references GeographicArea
county_or_city_id: int, references GeographicArea
street_address: varchar(255)
suite: nullable varchar(255)
Tambahkan line2, dan line3 jika perlu.
Lihat http://en.wikipedia.org/wiki/Address_(geography)
Sekarang, alamat adalah alamat. Banyak orang dapat hidup di suatu alamat, dan seseorang dapat memiliki banyak alamat pada saat yang sama, dan seiring waktu, sehingga Anda memerlukan banyak-banyak tabel untuk itu.
Alamat Pesta
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...}
Tambahkan a from_datedan nullable to_datejika melacak dari waktu ke waktu.
Suatu pihak dapat memiliki beberapa nomor telepon, dan nomor telepon dapat digunakan oleh banyak orang. Nomor telepon dapat digunakan untuk faks, panggilan telepon, modem, dll. Dan dapat memiliki ekstensi. Ini semua bisa berubah seiring waktu juga.
Nomor telepon
id: int
value: varchar(15) - the max allowed by the ITU
Min mungkin 3 (untuk "911"), atau mungkin 7 ("310-4NET", yang merupakan jenis khusus nomor lokal yang tidak memungkinkan Anda untuk memutar kode area)
Anda dapat membagi ini menjadi kode negara, dll jika perlu.
Anda harus menggunakan standar http://en.wikipedia.org/wiki/E.164
Nomor Pesta
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...}
Nama itu sulit. Inilah alasannya:
Beberapa orang memiliki nama resmi dengan hanya satu kata di dalamnya http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
Beberapa orang memiliki nama dengan banyak kata http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
Beberapa orang memiliki banyak nama pada saat yang sama (misalnya, di universitas saya ada banyak siswa Asia, tetapi mereka suka menggunakan "lebih disukai" nama yang lebih kebarat-baratan)
Terkadang, Anda perlu melacak nama orang dari waktu ke waktu, seperti nama gadis dan nama pernikahan.
Anda ingin mengabstraksikan individu dan organisasi untuk berbagai alasan yang bagus
membuat tabel pesta (id kunci utama server);
membuat tabel party_name (id kunci primer bigserial, party_id bigint bukan null referensi pihak (id), ketik smallint bukan null referensi party_name_type (id) --elided, ex "maiden", "legal");
buat tabel name_component (id kunci primer bigserial, party_name_id bigint bukan null referensi party_name (id), ketik smallint bukan null reference name_component_type (id), --elided ex "diberi" nama teks bukan null);
Dari perspektif yang sedikit berbeda dari jawaban sebelumnya, dan karena sepertinya OK untuk berbicara tentang LDAP , RFC 4519 - "Protokol Akses Direktori Ringan (LDAP): Skema untuk Aplikasi Pengguna" mungkin menarik.
Mungkin bermanfaat jika aplikasi Anda perlu dipetakan ke direktori tersebut. Kalau tidak, itu mungkin tidak disesuaikan dengan kebutuhan Anda.
Definisi-definisi ini lebih dari sekedar tentang data, mereka juga tentang beberapa operator yang dapat digunakan di lapangan. postalAddress, misalnya adalah a caseIgnoreListSubstringsMatch. Saya tidak menyarankan Anda untuk mematuhi skema ini dengan ketat, tetapi melihat prinsip-prinsipnya bisa menarik, khususnya bagaimana Anda harus membandingkan nama dan alamat dalam aplikasi Anda mungkin relevan dengan desain database Anda.
Mengenai nama, pertimbangkan untuk menggunakan tanda kutip ganda sehingga Anda tidak perlu melarikan diri dari tanda kutip dalam nama Irlandia atau Italia (misalnya, O'Hara atau D'Amato).
Saya juga merekomendasikan untuk menggunakan serangkaian Ekspresi Reguler yang baik untuk digunakan, sehingga Anda dapat menampilkan bagian bidang nama Anda (misalnya, inisial pertama, nama panggilan, Jr / Sr, dll.).