Jump to content

Datubāzes shēmas izveide


TOR
 Share

Recommended Posts

Vajadzīga palīdzība ar produktu testēšanas rezultātu datubāzes pareizu shēmas izveidi.

Pavisam vienkārši sakot vienam produktam var tikt veikti vairāki dažādi testi un katram veiktajam testam ir atšķirīgi iegūtie rezultāti. Piemēram, testā A tiek pārbaudīta triecienizturība, kur attiecīgi tiek glabāta informāciju par triecienu skaitu, bojāto paraugu skaitu utt, toties testā B tiek pābaudīts hermētiskums, kur jāfiksē spiediens bāros, spiediena zudums un tmldz.

Kāda būtu pareizākā pieeja? Katram iespējamajam testam veidot savu rezultātu tabulu? Vai veidot vienu kopēju rezultātu tabulu ar kolonnām, priekš visiem iespējamajiem mērijumiem/rezultātiem, kur katrs jauns ieraksts, aizpildīs tikai tos laukus, kurus nepieciešams, un pārējie paliks tukši? 

Tātad, kā pareizi sasaistīt tabulu, kura glabā informāciju par produktu, ar tabulu/-ām kuras glabā produktam piesaistīto testu rezultātus? 

Paldies jau iepriekš par idejām!

 

Link to comment
Share on other sites

Cik tev produktu un testi paredzēti? Varbūt nav jēga datu bāzi taisīt? Sabaksti visu Excelī un miers.

Link to comment
Share on other sites

Tieši no ekseļa es vēlos pāriet uz datubāzi, dēļ lielā produktu un testu apjoma, taču grūti ir pāriet no ekseļa izklājlapām uz datubāzēm..

Link to comment
Share on other sites

Pēc teorijas būtu pareizi

 

1. Tabula produkti,kur ir visa figņa par produktu 

2. Tabula tests, kur ir foreign key uz produktu un kaut kādi kopīgie dati par testu (passed, veikšanas laiks utt)

3. Tabulu klasifikatoru veidi 

4. Tabula testi_klasifikatori, kur many to many ir aprakstīti visi iespējamie testu dati + vērtības

 

 bet nu reālie Dj iemauktu visu kaut kādā dokumentu orientētā NoSQL DB ķipa MongoDB FTW un rulētu !!!

Labots - DjUbuntu
Link to comment
Share on other sites

Paldies, šķiet tas varētu derēt.

Varu palūgt tev uzskicēt vienkāršotu šo 4 tabulu ER diagrammu ar attiecībām? Tad man tā bilde būtu skaidrāka.

Link to comment
Share on other sites

Ņemot vērā, ka autors sāk jau rakstīt privātas ziņas, tad see attached 

 

 

Xwano7i.png

Link to comment
Share on other sites

Tīri teorērtiski pieejot problēmai izej cauri visam normalizācijas procesam soli pa solim un pie kautkā līdzīga nonāksi.

Link to comment
Share on other sites

Tikai man tāds stulbs jautājums - ja jau autors pats nespēj tik primitīvu DB shēmu pats izdomāt - kā viņš iedomājas šo dzīvē realizēt? 

 

Vai arī kārtējais haļavščiks, kurš izvēlējies nepareizu studiju virzienu un nu meklē ideotus, kas viņa vietā laborus pa velti taisīs! 

  • Patīk 1
Link to comment
Share on other sites

1. Nu vispār reālā dzīvē saprātīgāk būtu pičkāt iekšā tos rezultātus kaut kādā XML/JSON kolonnā, bet tas ir atkarīgs no izvēlās DBVS un workloada, kā arī gala klienta vides. Lai nepalielinātu suicīda līmeni LV, autoram neiesakam šo variantu apskatīt.

2. Ir vesela čupa ar nosql risinājumiem, kurus būtu vērts izskatīt (MongoDB (TokuMX) | CouchDB | Cassandra), bet iepriekšminētā iemesla dēļ nav ielikta :> 

Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...