☰

» »

db poizvedba

db poizvedba

BRBR :: 

f1  f2 

a   1
a   3
b   1
b   6 
b   10


Kako naj iz tega izvrtam samo 'a', ker ima vrednosti samo manjše od 4 ?

BRBR ::

ehh, že vidim, nekaj takega: 

where f2 < 4 and not f2 >= 4

Zgodovina sprememb…

  • spremenil: BRBR ()

vorantz ::

se pravi hočeš da ti vrne f1 je a in f2 manj od 4?
select f1 from tabela where f1=='a' and f2<4


edit: malo prehitro prebral vprašanje nvm

Zgodovina sprememb…

  • spremenil: vorantz ()

BRBR ::

Tista moja ugotovitev zgoraj ne pomaga še nič.

Zgodovina sprememb…

  • spremenil: BRBR ()

technolog ::

Boš moral pa malo bolj natančno opisat kaj hočeš.

BRBR ::

master

a  praprotnice
b  ena roža (species)


detail

a   kingdom           1
a   subkingdom        2 
b   kingdom           1
b   subkingdom        2
b   class             6
b   species           10


torej iz mastra je treba, na osnovi detail, izvrtat vse kar je večje od speciesa.
V tem primeru samo 'a'

Zgodovina sprememb…

  • spremenil: BRBR ()

BRBR ::

ja, takole:

select f1, max(f2)
from table
group by f1
having max(f2) < 4


samo stvar je zelo počasna na tapravih podatkih, indexi nimajo veze, so prav postavljeni

Spura ::

A v tretjem stolpcu je id kraljestva, vrste? Ali je pac v tretjem stolcu taxonomski nivo tega v srednjem stolcu?
Celoten podatkovni model se mi zdi zgresen, queryi pa so zaradi tega zakomplicirani in pocasni.
A ne bi bilo bolje imet to vse v eni tabeli? In podvajal se ti bo velik podatkov.

Zgodovina sprememb…

  • spremenil: Spura ()

BRBR ::

V tretjem stolcu je taxonomski nivo tega v srednjem stolcu.Kajpak je pa to tule samo demo, sicer je to mal drugače.

Spura je izjavil:


Celoten podatkovni model se mi zdi zgresen, queryi pa so zaradi tega zakomplicirani in pocasni.
A ne bi bilo bolje imet to vse v eni tabeli? In podvajal se ti bo velik podatkov.


Ja, je zgrešen in podatki se podvajajo, sem se en čas trudil imet hirearhično strukturo, v smislu:
parent_id  child_id
null       1 
1          2
1          3


in ker sem ugotovil da je nested model boljši od tega adjacent, kar tudi sicer v redu dela
sem poskusil tudi tule, kjer je več podatkov, samo se pa izkaže da se procedura adjacent to nested (MySql) na večji količini podatkov skoraj obesi,
t.j. na točki, ko sem se s tem ukvarjal sem ugotovil, da za več podatkov rabi exponentno več časa za pretvorbo.
Tako iz glave, 20 recordov iz adjacent naredi v hipu, 100 pa v 10 minutah.

Če to prijavim na MySql, se pa itak ne bo 100 let nič dogodilo.

Zgodovina sprememb…

  • spremenil: BRBR ()

Spura ::

Zakaj pa ne bi imel normalen model, kjer imas za vsako kategorijo svojo tabelo, npr.
TABLE KINGDOM K_ID K_NAME
TABLE CLASS C_ID C_NAME K_ID
TABLE ORDER O_ID O_NAME C_ID
TABLE FAMILY F_ID F_NAME O_ID
TABLE GENUS G_ID G_NAME F_ID
TABLE SPECIES S_ID S_NAME G_ID

To je normaliziran model, uporabljas joine, ki so na bazah dost hitri, semantika queryev je bolj jasna, ni podvajanja podatkov. Oziroma kingdom lahko spustis, imas itak samo enega: plants.

Zgodovina sprememb…

  • spremenil: Spura ()

BRBR ::

teh bi bilo toliko:
+x , ki mi morda manjkajo

join od vrha do dna po tvojem sistemu , pa po moje že ne bi bil več kaj preveč hiter

+ tu so še komplikacije s sinonimi:
division,40
phylum,40

itd.


level_name,level

life,1
domain,2
kingdom,10
subkingdom,20
branch,25
Infrakingdom,25
superphylum,38
division,40
phylum,40
subdivision,50
subphylum,50
Infraphylum,55
Microphylum,57
superclass,58
class,60
subclass,65
Infraclass,66
Parvclass,67
superorder,68
order,70
suborder,75
infraorder,77
Parvorder,78
superfamily,79
family,80
Subfamily,82
supertribe,84
tribe,85
subtribe,87
genus,90
subgenus,95
section,97
subsection,99
series,100
subseries,100
Superspecies,104
species,105
subspecies,110
infraspecies,111
variety,115
subvarietas,120
forma,125
subforma,130

Never underestimate the power of idiots in large groups.

Zgodovina sprememb…

  • spremenil: BRBR ()

WarpedGone ::

Mogoče se ti tole zdi veliko, ker še nisi vajen resnih baz. Resna zadeva z nekaj sto relacijami ni nič posebnega.
Divide Et Empera na dolgi rok zelo olajša življenje. V principu bi lahko čisto vse baze preuredil tako, da bi vse podatke porinu v eno samo tabelo (nekje v samem drobovju DBMS je zadeva itak temu precej podobna) ampak bi s tem projekt obsodu na smrt.

Če že moraš stvari tlačit skupaj, daj skup stvari ki ti logično (imensko) pašejo skupaj. Iz zgornjega nardiš recmo:
KINGDOM: PK, life, domain, kingdom
PHYLUM: PK, SK, subkingdom, branch, Infrakingdom, superphylum, division, phylum
CLASS: PK, SK, subdivision, subphylum, Infraphylum, Microphylum, superclass, class
ORDER: PK, SK, subclass, Infraclass, Parvclass, superorder, order
FAMILY: PK, SK, suborder, infraorder, Parvorder, superfamily, family
TRIBE: PK, SK, Subfamily, supertribe, tribe
GENUS: PK, SK, subtribe, genus
SECTION: PK, SK, subgenus, section
SERIES: PK, SK, subsection, series
SPECIES: PK, SK, subseries, Superspecies, species
VARIETY: PK, SK, subspecies, infraspecies, variety
FORMA: PK, SK, subvarietas, forma
SUBFORMA: PK, SK, subforma

PK je sekvenca, ki je primarni ključ posamezne relacije, SK pa tuj ključ na nadrejeno relacijo.
Takšna organizacija omogoča BISTEVNO hitrejše delovanje, kot brskanje in mnogokratno plezanje po isti tabeli. SQL v katerem maš povezane vse tabele, ni toliko počasnejši, kot si ti hitrejši pri obvladovanju zadev.
Zbogom in hvala za vse ribe

Spura ::

WarpedOne, pomanjkljivost tvojega modela je to, da je nadrejena stvar npr. genus-u je subtribe, ki je znotraj iste tabele. Hkrati je pa nadrejeno subtribe-u tribe, ki je pa relacija med tabelami. Pac ta dvojnost je.
Jst bi preprosto se drzal moje ideje, pa probal bi porezat stevilo teh identifikatorjev na manjso cifro.
V najslabsem primeru bi jst visje dele drevesa (ki so relativno majhni) zapisal v eno tabelo flat, potem bi zloadal na server in v Javi iz tega naredil drevo, ki bi ga imel cacheanega.
Sej ti ni treba imet vse logike implementirane na bazi.

WarpedGone ::

Alternativa:
DOMAIN: life, domain
KINGDOM: PK, SK, kingdom, subkingdom, branch, Infrakingdom
PHYLUM: PK, SK, superphylum, division, phylum, subdivision, subphylum, Infraphylum, Microphylum
CLASS: PK, SK, superclass, class, subclass, Infraclass, Parvclass
ORDER: PK, SK, superorder, order, suborder, infraorder, Parvorder
FAMILY: PK, SK, superfamily, family, Subfamily
TRIBE: PK, SK, supertribe, tribe, subtribe
GENUS: PK, SK, genus, subgenus
SECTION: PK, SK, section, subsection
SERIES: PK, SK, series, subseries
SPECIES: PK, SK, Superspecies, species, subspecies, infraspecies
VARIETY: PK, SK, variety, subvarietas
FORMA: PK, SK, forma, subforma

Smotarija zgornjega je, da maš nrp. šifrant subform, ki vsak zase v katero formo spada, šifrantu se reče pa FORMA - bol prav bi blo da bi bil šifrant/relacija SUBFORMA ampak pol maš pa cel model "čudn" - seznam model so sam ene sub/infra/parv/micro/infra zadeve, namesto bol splošno znanih pojmov, preko katerih se enostavneje orientiraš. Pa še N množnih kombinacij, kaj je "najboljš/najmanjslabo" je odvisno od vsebine same.

Velik je možnih rešitev, kjer ima vsaka rešitev svoj nabor pomanjkljivosti. Tehtat morš kater nabor je zate najmanj slab.
Sigurno pa je osnovna ideja z eno samo tabelo naslabša možna.
Zbogom in hvala za vse ribe

BRBR ::

Nisem ziher, ampak po moje je nested model taboljši. 1 tabela za vse + nikakršno podvajanje podatkov. Nekega lepega dne, ko bom imel čas se bom poglobil v to možnost.
Never underestimate the power of idiots in large groups.

WarpedGone ::

Ja, podvajanje je po defaultu slabo. Včasih je pa še vedno boljše kot alternativa.
Probi pesnit kompleksne SQLe nad hierarhično tabelo. Pazi da ne bo blizu kak mladoletnik, ker se zna naučit zanimivih grdih besed....
Zbogom in hvala za vse ribe

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Prenos vsebine z novega arhiva RTVSLO (strani: 1 2 3 4 5 6 7 8 )

Oddelek: Omrežja in internet		397102048 (1433) nijf
»

Sql poizvedba

Oddelek: Programiranje		111388 (892) zgubar
»

Matematika

Oddelek: Šola		313223 (2003) Math Freak
»

Maxima (matematični program)

Oddelek: Pomoč in nasveti		61073 (851) 2x'=2
»

MySQL Query Vprašanje

Oddelek: Izdelava spletišč		152968 (2733) overlord_tm

Več podobnih tem