Saya menghasilkan sub-skema basis data untuk menangani unit satu aeon yang lalu (oke, saya sedikit melebih-lebihkan; itu sekitar 20 tahun yang lalu). Untungnya, itu hanya harus berurusan dengan massa sederhana, panjang, dimensi waktu - bukan suhu, atau arus listrik, atau luminositas, dll. Agak kurang sederhana adalah sisi mata uang dari permainan - ada banyak sekali cara berbeda untuk mengkonversi antara satu mata uang dan lainnya tergantung pada tanggal, mata uang, dan periode di mana tingkat konversi berlaku. Itu ditangani secara terpisah dari unit fisik.
Pada dasarnya, saya membuat tabel 'ukuran' dengan kolom 'id', nama untuk unit, singkatan, dan satu set eksponen dimensi - masing-masing untuk massa, panjang, waktu. Ini diisi dengan nama-nama seperti 'volume' (panjang =3, massa =0, waktu =0), 'kepadatan' (panjang =3, massa =-1, waktu =0) - dan sejenisnya.
Ada tabel unit kedua, yang mengidentifikasi ukuran dan kemudian unit aktual yang digunakan oleh pengukuran tertentu. Misalnya, ada barel, dan meter kubik, dan segala macam unit relevansi lainnya.
Ada tabel ketiga yang mendefinisikan faktor konversi antara unit tertentu. Ini terdiri dari dua unit dan faktor konversi perkalian yang mengubah unit 1 ke unit 2. Masalah terbesar di sini adalah rentang dinamis dari faktor konversi. Jika konversi dari U1 ke U2 adalah 1.234E+10, maka kebalikannya adalah angka yang agak kecil (8.103727714749e-11).
Komentar dari S.Lott tentang suhu menarik - kami tidak harus berurusan dengan itu. Prosedur tersimpan akan mengatasi hal itu - meskipun mengintegrasikan satu prosedur tersimpan ke dalam sistem mungkin sulit.
Skema yang saya jelaskan memungkinkan sebagian besar konversi dijelaskan satu kali (termasuk unit hipotetis seperti furlong per dua minggu, atau yang kurang hipotetis tetapi sama-sama tidak jelas - di luar AS - seperti acre-feet), dan konversi dapat divalidasi (misalnya, keduanya unit dalam tabel faktor konversi harus memiliki ukuran yang sama). Ini dapat diperluas untuk menangani sebagian besar unit lain - meskipun unit tanpa dimensi seperti sudut (atau sudut padat) menghadirkan beberapa masalah yang menarik. Ada kode pendukung yang akan menangani konversi arbitrer - atau menghasilkan kesalahan saat konversi tidak dapat didukung. Salah satu alasan untuk sistem ini adalah bahwa berbagai perusahaan afiliasi internasional akan melaporkan data mereka di unit lokal mereka yang nyaman, tetapi sistem HQ harus menerima data asli dan menyajikan data agregat yang dihasilkan dalam unit yang sesuai dengan manajer - di mana masing-masing manajer berbeda punya ide sendiri (berdasarkan latar belakang nasional dan lama bertugas di markas besar) tentang unit terbaik untuk laporan mereka.
