SQL-lekérdezésként távolítsa el az adatbázisból nem létező információkat
SQL-lekérdezésként bontsa ki az adatbázisból a +11-et
- 15.06.16 01:25 •
- avshukan •
- # 303364 •
- Habrahabr •
- 34 •
- 9300
- ugyanaz, mint Forbes, csak jobb.
Egy ilyen ravasz címsor alatt meglehetősen egyszerű feladat rejlik, de először egy kis bevezető:
A felhasználók jönnek és megkérdezik: "Itt adtuk be az adatokat az adatbázisba, és mondd el, mi hiányzik? Milyen adatokat még nem léptünk be az adatbázisba, és nem elég a teljes boldogsághoz? "
Az első (és őszintén, nagyon buta) reakció: "Hogyan találhatom meg, mi van az adatbázisban?".
De elutasítjuk az érzelmeket és alkalmazzuk a logikát. Végtére is, mint általában, a szükséges adatokat, amelyek képződése során bizonyos szabályokat - csekkszám, hivatkozások és így tovább ... És azt feltételezik, hogy az összes ilyen számok és az azonosítók lehet alakítani egy természetes szekvencia.
Ez azt jelenti, hogy a feladat az alábbiak szerint fogalmazódik meg: az adatbázis tárolja a természetes számok sorát, amelyek hiányosak, és meg kell jeleníteni a hiányzó számokat a felhasználó számára.
Ebben a megfogalmazásban a probléma meglehetősen egyszerűnek tűnik. Ezenkívül van egy vágy, hogy ezt a feladatot egyetlen sql-lekérdezéssel hajtsák végre.
Hozzunk létre egy táblázatot, és töltsük fel néhány adattal.
Az alapötlet a következő: össze az asztalt, hogy maga és minden X értéke, hogy megtalálják a legkisebb y (ami még mindig több, mint Ix), ahol (X + 1) és (y - 1) lesz a határok nem fogadott számok tartományokat. Hozzáadása a logikai feltétellel, hogy (X + 1) legalább (y - 1) kapjuk a következő tartományokban: 4 és 4, 6-6, 10-10, és 13 és 15.
Melyek az árnyalatok:
1) A sorozat első eleme (esetünkben ez 1) elhagyható.
2) A sorozat utolsó eleme ismeretlen (és hirtelen 22). Természetesen kérheti ezt az információt a felhasználótól, de a tapasztalat azt sugallja, hogy jobb ezt elkerülni.
3) A "4-től 4-ig terjedő" tartomány hibásnak tűnik, egyszerűen csak egy számmal kell kicserélni
4) Az eredmény még mindig kívánatos egy vonal értékének megszerzésére, nem pedig sorok készítésére
Figyelembe vesszük a megjegyzéseket és kap egy szkriptet a MySQL számára:
és az Oracle alatt álló verzió:
Végrehajtásuk eredménye az "1-2, 4, 6, 10, 13-15, 18" sor.
Először is ez a sor tartalmazza azokat, amelyeket a felhasználók szeretnének.
Másodszor, az eredmény minden felhasználó számára egyértelműnek tűnik.
És főleg a lekérdezés olyan adatokat jelenít meg, amelyek tényleg nem tárolódnak az adatbázisban!
Opció a MySQL-hez az asmm-ből
Az Oracle az xtender számára
Az MSSQL lehetőség a yizraor-tól
Nos, ez egy közös ügy, nem sql ... A legegyszerűbb - meg egy jegyet (a vonat), ha nincsenek a jegyeket. Feature vasút és más hasonló rendszerek - régóta fenntartások az első a nagyvárosba kis állomás, pl Kiev Lehetne Darnitsa, Brovary, Bahmacs, Konotop - és ha a kijevi jegyek Moszkva nem szűk -, hogy ezekből a pontok lehetnek, és a legtöbb meglepő lesz a rendszerben, és a jegyeket nekik - és lehet, hogy ugyanabban az irodában vásárolni ugyanazon a vonaton-car-ülés - a lánc Kijev + Bahmacs Bahmacs Moszkva. (és ha a bontást újra Belgorodban végzik el - olcsóbb is lesz).
Itt a legfontosabb dolog a fejében, hogy van egy csomó, hogy "ha van valami valamilyen rendszerben, ez nem jelenti azt, hogy nem létezik egyáltalán", mint például: "van egy oázis minden üres helyen ... De nem minden teve megtalálja"
És ugyanúgy, mint egy olajfinomítóban, a rendszerben több kút elveszett ... (ami sokáig nem találta) ...
Több ember kamerákkal elveszíti rendszeresen - és mindkét végén a keresést fun -, hogy azok, akik élnek kevesebb kamerák. milyen telepítve nem csak hirtelen eszébe jut, hogy éppen ellenkezőleg, a földön - lóg a padlásszobában, szinte powered by fény, az áramlás a vezetés Wi-Faya, akinek, mikor, ki szállított - ismeretlen, a bérlők igyekeznek elhatárolni magát - nem a mi mondás ...
Egy korábbi munka (múzeum) gyakran szükségessé vált, hogy megtudja, mi leltári szám (amelyre az összes logikai alapja) hiányzik. A döntés lényegében ugyanaz volt, mint amit mutatni (az egyetlen különbség az, hogy a szám lehet a form [some_letters] 12345 [[START_NUMBER] [levél]] [-] [[END_NUMBER] [levél]] szögletes zárójelek - választható blokk).
Szerencsére létezett egy adatbázis, amelyen felsorolták a számok hézagait ([some_letters] 12345 [start-end] formában).
Request azonban az eredmény nehéz volt, mert nem volt még sok esetben ellenőrizni kell (a felhasználó belép egy rendkívül eltérő adatokat, és a végén kiderült, hogy a releváns keresési nem hiányzott a számok és a számok, melyek többször bejegyzések) .
Igen, a legegyszerűbb esetet tartottam (-:
A változók használata egyszerűbb lehet. Elvben a 3. szintű fészkelés nélkül is megteheti, de sokkal tisztábbnak tűnik.