Seberapa penting tabel pencarian?

Jawabannya sedikit tergantung jika Anda terbatas pada freeware seperti PostGreSQL (tidak sepenuhnya sesuai dengan SQL), atau jika Anda berpikir tentang SQL (yaitu, sesuai dengan SQL) dan database besar.

Sesuai dengan SQL, Arsitektur Terbuka database, di mana ada banyak aplikasi yang menggunakan satu database, dan banyak pengguna menggunakan alat laporan yang berbeda (bukan hanya aplikasi) untuk mengakses data, standar, normalisasi, dan persyaratan arsitektur terbuka adalah penting.

Meskipun orang-orang berusaha mengubah definisi "normalisasi", dll. agar sesuai dengan tujuan mereka yang selalu berubah, Normalisasi (ilmu pengetahuan) tidak berubah.

• jika Anda memiliki nilai data seperti {Open; Closed; etc } diulang dalam tabel data, yaitu duplikasi data , kesalahan Normalisasi sederhana:jika Anda mengubah nilai tersebut, Anda mungkin harus memperbarui jutaan baris, yang merupakan desain yang sangat terbatas.

  • Nilai tersebut harus dinormalisasi menjadi tabel Referensi atau Pencarian, dengan CHAR(2) short pendek PK:

    O  Open
    C  Closed
    U  [NotKnown]
    

  • Nilai data {Open;Closed;etc } tidak lagi diduplikasi dalam jutaan baris. Ini juga menghemat ruang.

  • poin kedua adalah kemudahan perubahan, jika Closed diubah menjadi Expired , sekali lagi, satu baris perlu diubah, dan itu tercermin di seluruh database; sedangkan pada file yang tidak dinormalisasi, jutaan baris perlu diubah.

  • Menambahkan nilai data baru , misalnya (H,HalfOpen ) kemudian hanya masalah menyisipkan satu baris.

• di Arsitektur Terbuka istilah, tabel Lookup adalah tabel biasa. Itu ada di katalog [sesuai SQL]; selama FOREIGN KEY relasi telah ditentukan, alat laporan juga dapat menemukannya.

• ENUM adalah Non-SQL, jangan gunakan itu. Dalam SQL, "enum" adalah tabel Pencarian.

• Poin berikutnya berkaitan dengan arti kunci.

  • Jika Kunci tidak berarti bagi pengguna, baiklah, gunakan {INT;BIGINT;GUID;etc } atau apa pun yang cocok; jangan beri nomor secara bertahap; izinkan "celah".
  • Tetapi jika Kunci tersebut bermakna bagi pengguna, jangan gunakan angka yang tidak berarti, gunakan Kunci Relasional yang bermakna.

• Sekarang beberapa orang akan masuk ke garis singgung tentang keabadian PK. Itu adalah poin yang terpisah. Ya, tentu saja, selalu gunakan nilai stabil untuk PK (bukan "tidak dapat diubah", karena tidak ada hal seperti itu, dan kunci yang dihasilkan sistem tidak memberikan keunikan baris).

  • {M,F } tidak mungkin berubah

  • jika Anda telah menggunakan {0,1,2,4,6 }, ya jangan diubah, kenapa mau. Nilai-nilai itu seharusnya tidak ada artinya, ingat, hanya Kunci yang berarti yang perlu diubah.

  • jika Anda menggunakan kunci yang bermakna, gunakan kode abjad pendek, yang dapat dengan mudah dipahami oleh pengembang (dan menyimpulkan deskripsi panjangnya). Anda akan menghargai ini hanya ketika Anda membuat kode SELECT dan menyadari bahwa Anda tidak perlu JOINs setiap tabel pencarian. Pengguna yang kuat juga, hargai itu.

• Karena PK stabil, terutama di tabel Lookup, Anda dapat dengan aman membuat kode:

  WHERE status_code = 'O' -- Open

  Anda tidak harus JOINs tabel Pencarian dan dapatkan nilai data Open , sebagai pengembang, Anda seharusnya mengetahui apa yang dimaksud dengan Lookup PK.

Terakhir, jika database berukuran besar, dan mendukung fungsi BI atau DSS atau OLAP selain OLTP (sebagaimana yang dapat dilakukan oleh database Normalisasi), maka tabel Pencarian sebenarnya adalah Dimensi atau Vektor, dalam Dimension-Fact analisis. Jika tidak ada, maka harus ditambahkan, untuk memenuhi persyaratan perangkat lunak tersebut, sebelum analisis tersebut dapat dipasang.

• Jika Anda melakukannya pada database Anda sejak awal, Anda tidak perlu memutakhirkannya (dan kodenya) nanti.

Contoh Anda

SQL adalah bahasa tingkat rendah, sehingga rumit, terutama dalam hal JOINs . Itulah yang kita miliki, jadi kita hanya perlu menerima beban dan menghadapinya. Kode contoh Anda baik-baik saja. Tetapi bentuk yang lebih sederhana dapat melakukan hal yang sama.

Alat laporan akan menghasilkan:

SELECT p.*,
       s.name
    FROM posts  p, 
         status s
    WHERE p.status_id = s.status_id 
    AND   p.status_id = 'O'

Contoh Lain

Untuk sistem perbankan, di mana kami menggunakan kode pendek yang bermakna (karena bermakna, kami tidak mengubahnya dengan musim, kami hanya menambahkannya), diberikan tabel Pencarian seperti (dipilih dengan cermat, mirip dengan Kode Negara ISO) :

Eq   Equity
EqCS Equity/Common Share
OTC  OverTheCounter
OF   OTC/Future

Kode seperti ini biasa terjadi:

WHERE InstrumentTypeCode LIKE "Eq%"

Dan pengguna GUI akan memilih nilai dari drop-down yang menampilkan
{Equity/Common Share;Over The Counter },
bukan {Eq;OTC;OF }, bukan {M;F;U }.
Tanpa tabel pencarian, Anda tidak dapat melakukannya, baik di aplikasi, maupun di alat laporan.