[multizync]

Nii, selline lugu, et kuidas saab teha kitsenduse ühele SQL andmebaasi tabeli veerule, et mida saab ühe päeva jooksul muuta ainult ühel korral.

[Sold OUT]

Tulistan puusalt, pole andmebaasidega süvitsi tegelenud rohkem kui baasi installimine ja tabelite loomine, täitmine, lugemine koolitöö tarbeks, aga: lisaväli ajahetkega kui veerus on andmed uuendatud, kui järgmine kord sinna vaja kirjutada, siis applikatsiooni poolt miskine kontrollskript, mis võtab lisaveeru väärtuse, kontrollib kas praeguse hetke ja kirjasoleva vahele jääb 24h ning kui saab positiivse vastuse, kirjutab veergu uue väärtuse ning fikseerib uue ajahetke. kui saab negatiivse tulemuse, siis väljastab veateate kasutajale (või on üldse vait) ning aja muutujat ei uuendata ning andmeid ka ei kirjuta tabelisse. Andmebaasides pole mõtet andmeid muuta vaid ikka lisada, terviklikkuse põhimõtte tagamiseks.

[Deadlock]

Parem variant on progeda vastav kontroll otse andmebaasi trigeri abil.
Et siis teed veel ühe veeru juurde, kus hoitakse aega ja iga kord, kui vastavat veergu uuendatase, läheb triger käima ja uuendab automaatselt aja kõrvalveerus ära või siis keeldub uuendamast, kui 24h pole möödas.

[Fukiku]

[multizync]

Hmm, mul ongi kaks andmebaasisüsteemi. Nagu, et mõlemas pean sama asja tegema. Ühe ja sama andmebaasi disainin Rel'is ja sama teen ka PostgreSQL's, postgresis on võimalik triggereid teha, aga Rel'is minu teada pole.

[Fukiku]

Aga milleks sul kaks andmebaasi, mis praegu sinu kirjelduse järgi teineteist dubleerivad?

[multizync]

Mu ülesanne näeb seda ette. Ma disainin kahes erinevas andmebaasisüsteemis projekti valmis ja siis pean võrdlema neid..

[2korda2]

Kui tegemist multimootori toega lahendusega, siis on mõistlik äriloogika baasidest väljaspool hoida. Ehk triggerid on paha mõte (pead tõenäoliselt igas mootoris eraldi kirjutama, iga muudatuse puhul jälle sama jama).
Tabelis olgu veerg tähendusega "viimase_muutmise_aeg", äriloogika kihis pärid selle väärtuse, teostad kontrolli ja vastavalt tulemusele toimetad edasi.

[Fukiku]

Kui inimene eelpool viitas, et tegemist on (kooli?)ülesandega, kus sama andmemudel tuleb realiseerida kahes erinevas andmebaasisüsteemis, siis ilmselt ei ole ärikihis tal võimalik ega lubatud neid muresid lahendada.

[2korda2]

Kui see tõesti nii on, siis ma kirjutaks ikkagi ülesande lahenduse juurde "* Päris elus hoitakse sellisel juhul äriloogika ärikihis." Kui põhjendus ka juures, siis viisakas õppejõud võiks selle eest lisapunkti anda.
Loomulikult saab probleemi triggeri/protseduuri vms abil ka baasis lahendada aga mõistlikuks ma seda ei pea.

[wiinanina]

[2korda2]

wiinanina,
ma ei saa sellest seletusest aru.
1. Kliendi adminil pole DBA ligipääsu, mis võimaldaks andmete/struktuuri muutust. Kui seda nõutakse, siis ühtlasi läheb lepingusse ka punkt, et vastutus läheb ka vastava admini õlule. Nii lihtne see ongi. Hoolduslepingud on päris ranged ses osas. Igasugu "huvilised" võivad äärmisel juhul saada select õiguse piiratud hulgale tabelitele/view-dele.
2. Eeldus, et DBA ei lähe triggeri/protseduuri kallale aga andmeid muudab mõnuga, on paremal juhul lihtsameelne. "Tavaliselt" = 50:60 = BS. Sellise asja peale lihtsalt ei tohi lootma jääda.

See, et mingeid funktsionaalseid muudatusi on baasi tasemel LIVE-s oleva rakenduse korral lihtsam/kiirem teha, kui rakenduses oleva loogika korral, on juba hoopis teine küsimus ja ei käi kindlasti selle teema alla.

[wiinanina]

[napoleon]

Siin on üks "aga". Kui mingi piirang on realiseeritud äriloogikas, siis sellest möödahiilimiseks ei olegi ilmtingimata DBA õigust vaja kuna sigadusi saab teha ka selle äriloogika kihi kasutaja alt ja selle kasutaja kättesaamise võib teha küll keeruliseks, aga mitte võimatuks.
Samuti on kliendil suhteliselt palju võimalusi asja kangutama hakata, kui tal andmebaasiserverile füüsiline ligipääs on. Ehk siis lolluste välistamiseks võib kliendi serveris või töökoha arvutis olla vaid presentatsiooni osa, ärioogika ja salvestuskihile ei tohiks klient füüsilist ligipääsu omada, kui eesmärk on välistada otse andmebaasi torkimine.

[multizync]

Tänud vastuste ja arutelu eest..

Mul oleks ühe asja kohta veel üks küsimus. Kui ma lisan tabelitele CHECK kitsendusi, siis kuidas oleks mõistlik teha. Kui mul on näiteks toa hinnale pandud kitsendus, et "Toa hind on alati positiivne arv". Siis CHECK kitsenduse puhul oleks korrektne panna, et "hind >= 0", kuna 0 on positiivne arv, aga reaalsuses, näiteks ma ei suuda kuidagi välja mõelda kuidas saaks Hotellis toa hind olla kunagi 0.
Samas võiks panna kitsenduse, et toa hind on suurem kui 0., CHECK kitsendus oleks siis (hind > 0), aga siis see on ju ka selge, et reaalsuses toa hind ei ole kunagi ka 0.5 euri või 1 eur vms. Mingit sümboolset nr nagu ei hakkaks ka ennustama, et alla selle hinna hotellis tube ei ole.

On keegi sellise asjaga kokku puutunud ja võiks öelda, kuidas oleks mõistlik selline kitsendus kirja panna. Või kui jääkski, et hind on alati positiivne, siis ära seletada, et millal võiks hind olla 0 euri näiteks.. Ma hetkel ei suuda seda välja mõelda..

Tänud ette..

[Deadlock]

Kui ülesandes on öeldud, et olgu positiivne, siis >0 ja kõik ju.
Sa ei pea andmebaasi pool muretsema selle pärast, et hind ei ole 0.5 euri. Aga mis siis, kui kunagi tuleb kampaania ja andmebaas ei luba kampaaniat läbi viia?
Ehk siis >0 kitsendus on mõeldud pigem selle pärast, et kogemata sattunud negatiivne arv kuskil süsteemis mingit kaost ei tekitaks.

[napoleon]

Hind võib ju teatud juhul 0 olla, näiteks mõne VIP majutamise puhul, kui tema hotellis viibimise fakt on juba ise piisavalt hea reklaam, samuti võib see teatud kampaaniate puhul 0 olla(näiteks ostad mingi muu toote/teenuse, saad majutuse tasuta). Kindlasti võib neid näiteid veel tuua.
Kui hinnapoliitika väga jäigalt paigas on, siis põhimõtteliselt saad ka foreign key teha, mis hinnakirjast kontrollib, aga mina jätaks pigem >=0

[Fukiku]

Alustuseks - matemaatiliselt ei ole null ei positiivne ega negatiivne arv.

Rääkides aga andmebaasidest ja infosüsteemidest - kui nõuetesse on kirjutatud, et "toa hind on alati positiivne arv", siis panedki tingimuseks hind > 0 .. pole sinu asi üldiselt sel kohal enam mõtlema hakata, et kas äkki peaks 0 asemel 1 või 5 vms. panema, sest 0.01 on sinu arvates ebatõenäoline. Arendaja üldiselt peaks tegema asju spetsifikatsiooni järgi .. kui spekk tundub kahtlane, siis tuleb sellest analüütiku või tellijaga rääkida ning koos üle täpsustada detailid. Omalooming ei ole siinkohal kindlasti asjakohane.

Ja millal on hind 0? Siis kui on vaja kliendile mett moka peale määrida .. mingit eelnevat äpardust heastada järgmisel külastusel tasuta toa pakkumisega?

edit: ja ette jõuti minust..

[2korda2]

Toa hind võib väga vabalt 0 olla:
a) kampaania korras loositi tuba välja,
b) tegemist on hotelliomaniku isikliku sviidiga,
c) tuba on tasuta juhul, kui kasutatakse piisaval hulgal muid hotelli teenuseid (kasiinodes VIP-d näiteks)
jne.
Päris elus on tüüpiliselt 101 erandit igale esialgu loogilisena tunduvale piirangule. Ka sellise piirangu seaksin mina äriloogika kihti.

[tähenärin]
0 pole positiivne arv. Pole ka negatiivne. Check ">=0" tähendab, et väärtus peab olema mittenegatiivne.
[/tähenärin]

[serk]

[napoleon]

[serk]

[wiinanina]

[multizync]

Tekkis veel üks mure. Mul on 2 tabelit,
Hinnaklass(hinnaklass_id SMALLINT, korruse_vahemiku_algus SMALLINT, korruse_vahemiku_lopp SMALLINT), milles on primary key hinnaklass_id
Tuba (nr INTEGER, hinnaklass_id SMALLINT, korrus SMALLINT), milles on primary key'ks nr ja foreign key'ks on hinnaklass_id

Hinnaklass tabel on mul valmis tehtud, ses suhtes, et mul on väärtused seal sees olemas. On 4 klassi hetkel.
Hinnaklass tabel

Nüüd on sellist asja vaja, et kui tabelisse Tuba lisada ridu, siis korrus peab jääma alati Hinnaklassi tabelis olevate korruse vahemiku alguse ja lõpu vahele. Proovisin selleks teha triggeri funktsiooni,(ühendades Tuba ja Hinnaklass tabelid JOIN'iga kokku) et enne Tuba tabelisse ridade lisamist käivitatakse funktsioon, midagi üritasin teha, aga ei tööta, või on midagi hoopis valesti

Spoiler

CREATE OR REPLACE FUNCTION f_kas_oige_korrus() RETURNS TRIGGER AS $$
DECLARE
BEGIN
PERFORM Tuba.hinnaklass_id, korrus, korruse_vahemiku_algus, korruse_vahemiku_lopp
FROM Tuba INNER JOIN Hinnaklass ON Tuba.hinnaklass_id = Hinnaklass.hinnaklass_id
WHERE korrus BETWEEN korruse_vahemiku_algus AND korruse_vahemiku_lopp;

IF NOT FOUND THEN
RETURN NEW;
ELSE
RAISE EXCEPTION 'Korrus peab jääma korruse vahemiku alguse ja korruse vahemiku lõpp vahele!';
END IF;
RETURN NULL;
END;
$$
LANGUAGE 'plpgsql' SECURITY DEFINER;

[napoleon]

Ma ei loe küll postgreSQL süntaksit päris vabalt, aga hetkel tundub, et kontrollid kas tabelis Tuba on vähemalt üks kirje, millel korruste vahemik korrektne on. Õige oleks tõenäoliselt midagi sellist:
PERFORM Tuba.hinnaklass_id, korrus, korruse_vahemiku_algus, korruse_vahemiku_lopp
FROM NEW INNER JOIN Hinnaklass ON Tuba.hinnaklass_id = Hinnaklass.hinnaklass_id
WHERE korrus BETWEEN korruse_vahemiku_algus AND korruse_vahemiku_lopp;

Võimalik, et seda NEW-d peab ka kuidagi teistmoodi käsitlema(ei viitsi hetkel pgSQL manuali lugema hakata) näiteks:
PERFORM Hinnaklass.hinnaklass_id
FROM Hinnaklass
WHERE NEW.korrus BETWEEN Hinnaklass.korruse_vahemiku_algus AND Hinnaklass.korruse_vahemiku_lopp
AND NEW.hinnaklass_id = Hinnaklass.hinnaklass_id;

Teine viga on selles, et minu arusaamist mööda on sul kontroll tagurpidi ehk peaks olema midagi sellist
IF NOT FOUND THEN
RAISE EXCEPTION 'Korrus peab jääma korruse vahemiku alguse ja korruse vahemiku lõpp vahele!';
ELSE
RETURN NEW;
END IF;