Fórumok
Szervusztok!
Kezdő adatbázis-bütykölő vagyok, az SQLite-tal birkózom. Ő áll nyerésre.
A tajszámokkal gyűlik meg most a bajom, amik ügye 0-val is kezdődhetnek, így csak azt a lehetőséget találtam, hogy text adattípusban tároljam őket. Namost szeretném elérni, hogy hármasával tagolódjanak a lekérdezésben, mert úgy jobban olvasható.
Van ehhez valamilyen pöpec lekérdezés, ami a formátumot is előírja a SQLite-nak, vagy mivel úgysem fogok vele műveleteket végezni, vigyem inkább úgy be? Bár el tudok olyan szitut képzelni, hogy valaki folyamatosan írva akar keresni.
Vagy eleve rossz adattípussal kezdtem?
Remélem érthetően írtam.
Hozzászólások
Szerintem szed ki belőle a "-" jeleket tároláskor, illetve kereséskor is szed ki, sőt kizárólag alfanumerikus adatokat engedj be. Így mindegy milyen formátumban írja a keresést úgyis meg fogja találni.
Hármas tagolást én a megjelenítési rétegre raknám, ugyanis a jövőben nem biztos csak belföldi adószámokat fogsz tárolni.
String teljesen jó, nem kell túlgondolni, fontosabb hogy jövőálló legyen.
Ha pedig tényleg SQL-ben akarod darabolni a megjelenítést, akkor egyszerűen:
Avagy csinálhatsz egy view-t:
És akkor ez a view mindig az eredeti tábla adatait mutatja a definiált formátumban.
De valóban jobb lenne ezt frontend oldalon kezelni.
A TAJ ugyebár nem szám, hanem számjegyeket tartalmazó string (ahogy az adószám sem szám, meg a személyigazolvány-szám sem szám). Emiatt az adatbázisban sem számként tárold, hanem stringként.
Így is dolgozd fel, és adatbázisban is így tárold.
A formázást pedig ne az adatbázis lekérdezéskor csináld, hanem amikor azt a TAJ-t meg kell valahol jeleníteni, vagy el kell valahova küldeni, akkor a megjelenítés/küldés formátumára konvertáld.
Például lehet, hogy felhasználók felé fontos a hármas tagolás, míg lehet, hogy egy gépi interfészen meg a nyers, tagolás nélküli TAJ kell. Az adatbázisból kiszeded nyersen, és mindenhova úgy írod ki, ahogy ki kell írni.
1, Szám az, amivel matematikai műveletet akarsz végezni, minden más szöveg.
2, Tárold tömören, szigorúan adattisztítva (!), validálva, majd a megjelenítésnél formázod, ahogy csak akarod, különben egy csomó szopást húzol magadra.
https://iotguru.cloud
+1, a TAJ-szám tartalmaz egy checksum-ot, azt mindenképp ellenőrizni kell a DB-be írás _előtt_.
Nevezetesen a számjegyeket (balról kezdve) felváltva 3-mal és 7-tel szorozva összeadjuk, és a maradékot modulo 10 véve kapjuk az ellenőrzőszámot.
+1 Amit masok is irtak. Tiszta adat, frontend formazas. Mi a frontend amit hasznalsz? A legtobb webapp cucc ezt siman lekezeli.
Ha mégis számként akarod tárolni, és csak az a baj, hogy kezdődhet 0-val, akkor írj elé egy 1-est, megjelenítéskor meg szedd le! :-)
De tényleg csak vicc volt, mert ahogy fentebb is írták, stringként érdemes tárolni. És ha kellhet külföldi TAJ is, akkor arra is fel kell készülni, hogy annak is legyen hely, és menjen át az ellenőrzésen! Viszont az adattisztítás is jó ötlet: egy dolog egyféleképpen szerepelhessen, hogy később ne legyen ebből probléma!
"Bár el tudok olyan szitut képzelni, hogy valaki folyamatosan írva akar keresni."
Amit keresel, az az input normalizálása. A TAJ az 8+1 darab számjelgy karakterből álló string (8 értékes jegy és egy checksum), mivel nem egy legfeljebb 9 jegyű számként használod, így a bevitelnél (rögzítés és keresés egyaránt) a numerikus karaktereken kívül midnent ki kell takarítani az inputból, aminek így egyrészt pontosan 9 karakter hosszúnak kell lennie, _és_ a cheksum-nak is rendben kell lennie.
Házi feladat: a TAJ-számban található checksum pozíciójának és kiszámításának utánanézni.
A TAJ szám egy kilenc számjegyből álló szám, amelyben az első nyolc számjegy egy folyamatosan kiadott egyszerű sorszám, amely mindig az előző, utoljára kiadott sorszámból egy hozzáadásával keletkezik.
A kilencedik számjegy ellenőrző ún. CDV kód, melynek képzési algoritmusa az alábbi:
forrás: https://github.com/karsany/hunlib4j/issues/4
Saját TAJ számon ki kellett próbálni. Én megtettem, nekem ment
Köszönöm! Ráállok a témára!