- Apple notebookok
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen processzort vegyek?
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- AMD GPU-k jövője - amit tudni vélünk
- Vezetékes FEJhallgatók
- Xiaomi Pad 5 - hatásos érkezés
- Házimozi haladó szinten
- HiFi műszaki szemmel - sztereó hangrendszerek
- Hogy is néznek ki a gépeink?
Hirdetés
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
A franciáknak elege van abból, hogy minden gyerek mobilozik
it Vissza akarják szorítani a gyerekek és tinédzserek közösségi média- és okostelefon-használatát.
-
Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
ph Egy tesztelő több száz processzorral elemezte a helyzetet, és a legdrágább komponensekkel nagyon siralmas a helyzet.
Új hozzászólás Aktív témák
-
Totu
csendes tag
Hello mindenki!
Eddig csak a hírlevél miatt voltam fent a lapon, de most jött egy kérdésem, amit hirtelen nem tudok kimatekozni.
A kérdés MS SQL Server-rel kapcsolatos, mégpedig a következő:
Elég profinak érzem már magam mindenféle SQL-es dologban, és most viszek is egy komolyabb projektet, ami kezd kilépni a gyerekcipőből.
A problémám, hogy van egy éles rendszer, amin eddig fejlesztettem, és eljött az a pillanat, hogy nem lehet "garázdálkodni" az éles rendszeren, tehát tükrözéssel egy alternatív adatbázisba kell tenni mindent, és ott végrehajtani a fejlesztéseket.A gondom csak ott van, hogy a fejlesztés során a mechanika néha élesen változik, és a régi mechanikát nem tudom hogy írjam felül az adatok sérülése nélkül.
Tárolt eljárásokat simán lehet SQL batch-ből update-elni, ez nem gond. (előtte ugye egy DB tool segítségével exportálni a fejlesztett scripteket)
Csak ott van a gond, ha a táblastruktúrák változnak. Ez nem nem olyan gyakori, de annál nagyobb problémát okoz, ha a változások száma meghalad egy bizonyos számot.Gyk. lehetetlen lenne fejben tartani, hogy a szoftver melyik verziója milyen struktúrában volt/van, és mit és hol kell átírni.
Szeretném elkerülni, hogy az adatokat is exportálni kelljen, mielőtt a verziót frissítem, mert ez néha elég hosszúra nyúlhat... (sok adat keletkezik)
De lehet, hogy nem tudom elkerülni... ?Tömören: mi a hivatalos módja annak, hogy egy meglévő adathalmazt egy felülről kompatibilis struktúrára ráhúzzak?
Lehet, hogy megválaszoltam már magamnak a kérdést, de kíváncsi lennék a ti véleményetekre is!
üdv,
Totucordiali saluti, Totu
-
Totu
csendes tag
Á, értem!
Nos a helyzet az, hogy kisebb cég, egyedül csinálom a szoftvert, és mivel adatbázisok szintjén ilyesmivel még nem volt dolgom, gondoltam megkérdezem, hogy ennek mi a módja a nagyoknál?
A választ megkaptam, már csak azt nem tudom, hogy hogyan döntitek el, hogy mi a változás? Vagy biztos ami biztos az egész struktúrát lemódosítjátok?cordiali saluti, Totu
-
Totu
csendes tag
Hali!
Dehogynem tudom, mi a fejlesztés, csak eddig nem kellett trükközni, mert az "éles" rendszer volt a fejlesztői is. Tudom, hogy ez hosszú távon nem tartható, ezért kérdeztem, milyen kényelmes módja van a frissítésnek.
Van 40 táblám kismillió relációval és index-szel, 100 eljárás, 15 függvény, ezeknek a száma még természetesen nőni fog, tudom, hogy ez nem olyan nagyon sok, de egyedül fejben tartani lehetetlen és egyébként is marhaság.
Az SVN-es ötletet jónak tartom, majd én is bevezetem. Köszi!
Egyébként nem vagyok olyan fejetlen, mint amilyennek tűnök néha.
Csak eddig számomra ismeretlen területre tévedtem, és gondoltam megkérdezem.
És ahogy mondják: kérdezni nem szégyen, pláne ha ingyen van.Úgyhogy köszi a választ!
cordiali saluti, Totu
-
Totu
csendes tag
Hali!
Megint jöttem kicsit agybajt hozni rátok.
A kérdés az, hogy hogyan lehet/kell többes mezőkkel relációkat létrehozni?Megmutatom a példát, ami a dilemmát okozza, és azon magyarázom el, hogy mi vele a gondom.
PK: primary key (az egyértelműség kedvéért)
FK: foreign key (egyértelműség kedvéért)model(id PK, desc, ...)
part(id PK, desc, defaultPN FK->pn.id)
pn(id PK, part FK->part.id)
modelpart(model FK->model.id, part FK-> part.id)ez eddig egyszerű, mint a szög: vannak modellek, alkatrészek, egy alkatrész több modellhez lehet hozzárendelve, az alkatrészeknek vannak PN-jeik, és nekem kell az is, hogy melyik az aktuális PN, de ez nem olyan lényeges. a gond itt kezdődik(a fentiekhez hozzáadva):
modelevent(id PK, model FK->model.id, time, ...)
modeleventPN(modelevent FK->modelevent.id, pn FK->pn.id)ez a reláció önmagában nem garantálja nekem, hogy nem tudok olyant PN-t beszúrni a modelevent PN-jeihez, ami nem szerepel a modelpartban.
hol lehet létrehozni a kötést, ami megmondja, hogy akkor szúrhatom be a megfelelő PN-t, ha a modelpartok között van olyan, aminél stimmel a model, és stimmel a PN-hez tartozó part?
erre muszáj check constraint-et rakni, vagy ügyes relációval lehetséges?
Remélem érthető voltam, és nem zagyváltam össze itt senkit.
cordiali saluti, Totu
