[SQL] MySQL, MSSQL, TSQL,... Kaj priporočate in kaj uporabljate

Kot prvo... T-SQL nima kaj iskati med tem, kaj uporabljamo, če zraven mešaš še mySQL in MSSQL. MSSQL in mySQL sta podatkovni bazi, T-SQL pa je razširitev samega jezika.

Osebno sem pristaš MSSQL-a, saj se mi zdi najbolj profesionalen in hkrati enostaven za uporabo. Ne bom trdil, da je boljši od npr. Oracla, PostGreSQL, ipd., sem ga pa bolj navajen, v njem bolje in lažje naredim vse, itd. Tudi sama sintaksa se mi zdi bolj naravna, kot drugje. Najbolje se zlije z ostalimi MS tehnologijami in orodji (.NET, Office, SSIS, SSAS, Office...).

Na splošno ni mogoče soditi o tem, kateri je boljši. Lahko le rečeš, kateri je boljši za določen namen. Jaz za svoje DIY domače projekte uporabljam MySQL, ker je zanesljiv, hiter in enostaven za postavitev in uporabo. Ko ga namestiš lahko praktično pozabiš nanj. Foter ima računalniško firmo in delajo z Oraclom in MS SQLom. Po njegovem pripovedovanju sta to bolj profi zadevi, ki sta tudi kompleksnejši za postavitev in vzdrževanje.

Spura je 2. feb 2016 ob 18:51 izjavil:

Ne vem za MSSQL, ampak gotovo je Postgre boljsi od MySQL, Oracle in DB2 sta pri velikih podjetjih mocno precenjena.

Vse skupaj je eno in isto sranje. Ene baze so boljše nekje, drugje drugje, bistvenih razlik ni. Vzameš bazo, ki jo razvijalci najbolj obvladajo.

Glede na to, da je hardware drek-pekec cene celotnega stroška, si le tega lahko nabildaš v nulo in presežeš omejitve razvijalcev. Do neke mere.

Ko nekdo reče, da se mu dopade, smatram izjavo za enako kredibilno kot izjavo, da se meni bolj dopadejo rdečelaske kot blondinke. Ni to baš neka strokovna referenca.

Koliko firm pa rabi Oracle EXA? V Sloveniji nobena. Ja, milijon v firmah, kjer to res rabijo, je v primerjavi ceno folka, ki zna to uporabljati, in ostalimi licencami, drekec-pekec.

Invictus je 2. feb 2016 ob 21:00 izjavil:

Spura je 2. feb 2016 ob 18:51 izjavil:

Ne vem za MSSQL, ampak gotovo je Postgre boljsi od MySQL, Oracle in DB2 sta pri velikih podjetjih mocno precenjena.

Vse skupaj je eno in isto sranje. Ene baze so boljše nekje, drugje drugje, bistvenih razlik ni. Vzameš bazo, ki jo razvijalci najbolj obvladajo.

Glede na to, da je hardware drek-pekec cene celotnega stroška, si le tega lahko nabildaš v nulo in presežeš omejitve razvijalcev. Do neke mere.

Se ne strinjam z nicemer od napisanega.

Ja, je drekec pekec, ampak problema pa ne reši zmeraj.

Dobro, velike količine podatkov... Na MSSQL obračamo miljarde rowov na tabelo (podatkov v bazi je cca 4.8TB), pa leti k šus... seveda ogromno pripomorejo partition switchi, lepo napisan software in tudi zajeten hardware. Dnevni prirast je ~800mio vrstic na dan (v celi bazi - od tega v največji tabeli cca polovico tega). In ne, niso tako ozke tabele (največja meri cca 25 columnov v širino).

Si pa ne predstavljam kaj takega postavit na mySQL. Na PostGreSQL še, na mySQL pa ne. Bom pa poskusil, za voljo argumenta.

Jaz osebno ne maram prevelikih tabel, sploh ce se stari podatki (npr vec kot 60 dni) ne potrebujejo takoj.
Zato imam sistem, ki mi dnevno vse starejse zapise (odvisno od konfiguracij) da v retention tabele (v bistvu mesecna tabela za vsak server/bazo/tabelo), SW je pa tako spisan, da ce so datumski pogoji bolj za nazaj, gre gledati tudi te tabele (kjer je struktura enaka).
Nekje za 5 let se hrani posamezna tabela, tud lazje je starejse potem brisati, ko se ne potrebujejo vec.

Saj ves, navada je zelezna srajca. Sploh ce izvira iz dobe, ko smo se sparal na baytih :)
Na Oraclu particije skoz uporabljamo, in vem da je lustno, sem parkrat ze hotel pogledati particioniranje pri Mysql, ampak cajta zmeri zmanjka.

Groove je 4. feb 2016 ob 00:40 izjavil:

S particijami te težave nimaš ("težje" brisanje), saj postane le-to metadata operacija. :) Par sekund, pa pobrišeš vse, kar rabiš.

Ja... če ti to dovoljuje software in/ali uporabniki. Od npr. 15mrd rowov velike tabele je cca 8mrd rowov tekoče okno zadnji desetih dni (starejše se briše, ohranja se pa še nekatere zgodovinsko izredno pomembne podatke)... :)

Particioniranje je zakon. Uporabljamo to na enem projektu, kjer se nabere dnevno precej giga podatkov. Ena particija je dan podatkov. Po 3 dneh se particija zbriše. Delete dela neskončno dolgo. Brisanje particije je trenutno. Delamo pa z DB2.

          je 3. feb 2016 ob 07:50 izjavil:

Neoptimalno napisan SW težko rešuješ samo s hardwerom.

Do neke mere pomagajo SSDji in RAM.

Zato pa pravim, da je cena hardwara drekec-pekec. Dober inženir lahko stane v enem letu več kot ves hardware in software za ta projekt.

Naredi si virtualno mašino.

kunigunda je 4. feb 2016 ob 15:08 izjavil:

Groove je 4. feb 2016 ob 00:40 izjavil:

S particijami te težave nimaš ("težje" brisanje), saj postane le-to metadata operacija. :) Par sekund, pa pobrišeš vse, kar rabiš.

Ja... če ti to dovoljuje software in/ali uporabniki. Od npr. 15mrd rowov velike tabele je cca 8mrd rowov tekoče okno zadnji desetih dni (starejše se briše, ohranja se pa še nekatere zgodovinsko izredno pomembne podatke)... :)

Me pa kar firbec malo, kaj ima lahko clovk v 15mrd rowov ene tabele :)

Pogodbe. Veliko pogodb. Na urni osnovi (različna cena in količina), spreminjajo se dnevno. Pogodbe trajajo tudi po 5 let v prihodnost.

kunigunda je 4. feb 2016 ob 17:25 izjavil:

10miljard+ pogodb v 10 dneh ?

Groove je 4. feb 2016 ob 15:17 izjavil:

Pogodbe. Veliko pogodb. Na urni osnovi (različna cena in količina), spreminjajo se dnevno. Pogodbe trajajo tudi po 5 let v prihodnost.

Še enkrat preberi Vsaka pogodba ima cca 8760 zapisov za eno leto. Če traja pogodba 5 let, je to švoh 44k zapisov.

cca 12k takih pogodb je že 500mio rowov.

Poljubno slab design lahko napolni poljubno velik disk.

Easy there, tiger.

Napisal sem dnevni prirast 800mio recordov na dan, od tega polovico v največji tabeli.

In še enkrat. Ena pogodba BP traja 5 let. 5 let, urni nivo. Celotna poodba se vsak dan znova izračuna.
Se pravi vse (aktivne) pogodbe se preračunajo vsak dan, iz česar se potek vidi tudi evolucija. In ja, (lahko) se spremeni količina/cena (in še miljon ostalih parametrov) za vsako uro - vsak dan. Delajo se torej "snapshoti" dnevnega stanja.

Poveži to še s tem, kar je napisal Ziga Dolhar :).

In brez skrbi, pri zadevi, o kateri pišem, ni slabega dizajna. V nasprotnem primeru bi bil performance katastrofalen.