sql >> Databáze >  >> RDS >> PostgreSQL

rozměrová a jednotková analýza v SQL databázi

Před eonem jsem vytvořil podschéma databáze pro manipulaci s jednotkami (dobře, mírně přeháním; bylo to však asi před 20 lety). Naštěstí se musela vypořádat pouze s jednoduchou hmotností, délkou, časovými rozměry – nikoli teplotou, ani elektrickým proudem, ani svítivostí atd. Spíše méně jednoduchá byla měnová stránka hry – existovalo nespočet různých způsobů převodu mezi jednou měnou a další v závislosti na datu, měně a období, po které byl směnný kurz platný. To bylo řešeno odděleně od fyzických jednotek.

V zásadě jsem vytvořil tabulku 'míry' se sloupcem 'id', názvem jednotky, zkratkou a sadou exponentů dimenze - po jednom pro hmotnost, délku, čas. Toto se zaplní názvy jako „objem“ (délka =3, hmotnost =0, čas =0), „hustota“ (délka =3, hmotnost =-1, čas =0) – a podobně.

Existovala druhá tabulka jednotek, která identifikovala míru a poté skutečné jednotky používané konkrétním měřením. Byly to například sudy, kubické metry a všechny možné další důležité jednotky.

Existovala třetí tabulka, která definovala převodní faktory mezi konkrétními jednotkami. Ten se skládal ze dvou jednotek a multiplikativního převodního faktoru, který převáděl jednotku 1 na jednotku 2. Největším problémem zde byl dynamický rozsah převodních faktorů. Pokud je převod z U1 na U2 1,234E+10, pak je převrácené číslo poměrně malé číslo (8,103727714749e-11).

Zajímavý je komentář od S.Lotta o teplotách - ty jsme řešit nemuseli. Uložená procedura by to řešila – i když integrace jedné uložené procedury do systému mohla být složitá.

Schéma, které jsem popsal, umožňovalo většinu převodů popsat jednou (včetně hypotetických jednotek, jako jsou furlongy za čtrnáct dní, nebo méně hypotetických, ale stejně nejasných – mimo USA – jako akr-stopy), a převody bylo možné ověřit (například oba jednotky v tabulce konverzních faktorů musely mít stejnou míru). Mohlo by být rozšířeno, aby zvládlo většinu ostatních jednotek - ačkoli bezrozměrné jednotky, jako jsou úhly (nebo plné úhly), představují některé zajímavé problémy. Existoval podpůrný kód, který by zpracovával libovolné konverze - nebo generoval chybu, když konverzi nemohla být podporována. Jedním z důvodů pro tento systém bylo to, že různé mezinárodní přidružené společnosti hlásily svá data ve svých místně vhodných jednotkách, ale systém ústředí musel akceptovat původní data a přesto prezentovat výsledná agregovaná data v jednotkách, které vyhovovaly manažerům – kde každý z nich měl různé manažery. měli vlastní představu (na základě jejich národního původu a délky služby v velitelství) o nejlepších jednotkách pro jejich hlášení.



  1. Neuspořádané výsledky v SQL

  2. Volejte uloženou proceduru pro každý řádek vrácený dotazem v MySQL

  3. Dva sloupce jako primární klíče v mysql?

  4. Audit trail s Entity Framework Core