Datubāzes vienas tabulas sadalīšana kvalitatīvā datubāzē

[bluebird]

Sveiki!! :)

Es turpinu savu mazo piedzīvojumu DB pasaulē! :)

 

Pagaidām esmu ticis līdz šai vietai!!

 

Tad nu kad ķēros pie PHP formu ģenerēšanas attapos, ka man vēl tik daudz kas jāpalasa, lai varētu uzģenerēt formu priekš datubāzes kurā ir relācijas! :)

 

Ja es pagaidām visus datus vāktu vienā tabulā bez relācijām kurai būtu uzģenerētas PHP formas es varēšu pēc kāda laika bez īpašiem sarežģījumiem šos datus sadalīt datubāzē ar relācijām??

Piemēram es pus gadu vākšu tos datus un izmantošu un piemēram pēc pus gada man būs gatava datubāze ar tiem pašiem laukumiem tikai jau smuki strukturizēta.

 

Neapspriežam to vai man pietiks prāta, bet cik liela ir sarežģītības pakāpe! :)

 

Paldies!! :)

[Gints Plivna]

Tādā gadījumā rodas klasiskās datu migrācijas problēmas - ir vairāki ieraksti (piemēram, klientiem) kuriem normalizētā db būtu jāpārvēršas par vienu ierakstu. Problēmas - pirmām kārtās šos ierakstus savilkt kopā un saprast, ka palagā (excelī/whatever) 10 vietās dažādi aprakstītais klients ir viens un tas pats. Vispārīgā gadījumā , ja nav identifikatora pēc kura to atrast, tas rada nevājus sarežģījumus un parasti nav 100% korekti algoritmiski izdarāms. Otrais - ja esmu tomēr savilcis, ka klients ir viens un tas pats, tad no kura ieraksta ņemt atribūtus, kurus uzskatīt par korektajiem, jo 100 punkti, ka tie dažādiem ierakstiem atšķirsies.

Tavā gadījumā citas lietas, kas mēdz arī būt migrējot datus (nepilnīgi lauki, veci klasifikatori, teksts kas nav klasificēts utt utjp) diez vai būs. Datu apjoms pusgada laikā arī nevar būt problēma.

Visas šīs problēmas ir tieši proporcionālas datu daudzumam un pieejamo nēģeru atvainojiet manuālo datu ievades operatoru skaitam un pieejamām darba stundām. Ja ir 100 ierakstu, tad nav vērts saspringt. Ja ir 10K ierakstu un daži cilvēki un nepieciešamais laiks, tad arī nav vērts saspringt. Ja ierakstu skaits ir mērāms miljonos un vairāk, tad ir jābūt jau nopietnam cilvēku skaitam un laikam, lai to visu manuāli/pa pusei manuāli apstrādātu, bet parasti tad manuāli nekas vairs nenotiek.

 

Gints Plivna

http://datubazes.wordpress.com

 

P.S. Ir nācies pāris reizes ko tādu darīt vismaz Latvijas mērogiem lieliem datu apjomam, tā kā ir zināma pieredze :)

Edited September 8, 2010 by Gints Plivna

[Vhubuo]

Ja jusu datubāzes shema ir tada ka iepriekšaja topika, tad lielo saražģibu nebus. Jo nav ipaši daudz objektu.

Bet jums ir jāzin ka arejas atslegas dod jūms drošibu par datu vienotibu.

Piemēram Addrese. Ja jus rakstiet to viena tabula tad jums var but dažadas adreses "Jaņa iela 1a" un "Jaņa iela 1A". Bet ar relacijam jus veicat parbaudi ka maja var but tikai "1a".

Tas ir DRY princips.

Bet ja jūms patik stradat ar vienu tabulu, to var emulet ar VIEW. Tadejadi jus saglabasie relaciju strukturu un stradasiet ar vienu tabulu.

Edited September 8, 2010 by Vhubuo

[bluebird]

Ok! :)

Tavs teksts ir pietiekami pārliecinošs, lai es tomēr pacīnītos tagad un izveidotu jau kārtīgu pamatu tam visam! :)

 

Ir kāda prātīga literatūra latviešu valodā par šo tēmu - grāmatas!!?

Tieši par datu bāžu modelēšanu un dažādām problēmām ar kādām var nākties saskarties utt?? Kur apskatītas situācijas un risinājumi no teorētiskās puses!! :)

[Gints Plivna]

AFAIK latviešu valodā nav nekas

Domāju, ka arī angliski inetā ja godīgi ir tikai druskas, tb info jāvāc kopā no 100 vietām, kur ir katrā kaut kas pa druskai labs un druskai ne pārāk.

Bet es tā īsti neiebraucu - 3 tabulas Tev ir, sākotnējās vajadzības tas apmierina. Ko vēl vajag? Ar perfekcionismu arī nevajag aizrauties, tas arī ne pie kāda laba gala neved, jo tā nevienu programmu nevar pabeigt nekad.

Uzrauj to, kas ir skaidrs, sāc lietot, tāpat atradīsies lietas par kurām nelietojot neiedomāsies.

[bluebird]

Es par to padziļinātu lasīšanu nejautāju tādēļ, ka man vajag pārtaisīt datubāzi,jo pagaidām pieturēšos pie jau izveidotā modeļa, bet gan tādēļ, ka vienkārši interesē palasīt vairāk!! Vienk sportiska interese!! :)