Voleo bih da ovde nastavimo diskusiju koja se povela na drugoj temi, pa sam izdvojio poruku u novu temu.

Skoro sam radio neki alter na tabeli od 9+M redova i deploy - kad se ugl. ispucavaju migracije je trajao dobrih 45 min. Brine me sta ce biti u buducnosti kad jos poraste tabela, sta bi ti predlozio za ovako velike izmene na live (ili dev ali podjednako velikim) bazama?

ORM-ovi su cool za CRUD, za bilo sta sto ukljucuje vise tabela samo custom SQL, naucio na svojim greskama

Glupo pitanje: Pošto dolazim iz Oracle okruženja, na kojoj to bazi podataka dužina izvršavanja ALTER TABLE zavisi od broja redova u toj tabeli?

Oracle ALTER TABLE samo menja JEDAN slog u SYS šemi u tabeli objekata, a ne sve redove u tabeli.

Prvo, ja bi gledao da mi dizajn bude kako treba. To je osnovno. Baze podataka se dizajniraju u skladu sa normalnim formama. 3./BC minimum 4. izuzetno pozeljno. Denormalizacija se radi, ali, posto prvo uradis normalnu bazu. Po meni, tako treba poceti, znam da je agile reci samo YAGNI i ici sa ORM-om, ali, po meni, ako projekat ima ikakve sanse da naraste, tj. ako baza nije samo storage - treba odvojiti vreme.

Drugo, Bogdan mi je jednom ovo rekao, sto sam mnogo dobro zapamtio "Denormalizaciju radis kad si siguran i obavezno zapises STA si uradio i ZASTO jer ce ti trebati to za par godina"... parafraziram. :) Nadam se da ce on da se ukljuci, zna mnogo vise o bazi od mene. :)

Trece, kad su baze pocele da se koriste, nije bilo clustera. Zato su isle dinamicke forme, kao EAV model. Ti u EAV modelu, kad hoces da dodas cipele ne dodajes u tabelu "predmet" kolonu "broj cipela" alterom, ti samo dodas atribut "broj cipela" u tabelu atributa, "46" u tabelu vrednosi i srucis za cieple broj 46 par slogova u vezne tabele. Ova sema, osim sto smanjuje kolicinu date i normalizuje podatke ima i prednosta da omogucava dodavanje osobina bez altera.

Kad si sve sto mozes iscrpeo, a moras da imas alter, onda gledas resenja specificna za bazu. Ja cu sad preci na MySQL njega najvise koristim za ovakve stvari:

MySQL replikacija ima zgodnu foru da, ako uradis alter na slave-u, tako da alterom dodajes kolonu NA KRAJ tabele (obavezno vodis racuna kad pises alter) replikacija ce nastaviti da radi. U bilo kom slozenom sistemu, gde imas master i bar dva slave-a, ti mozes bez problema da napravis alter na slave-ovima, proglasiss jedan od njih za novi master, i onda uradis alter na preostaloj masini. Malo je igranka i radi se u krug, ali tako mozes da radis alter tabele i od 100GB bez da ista pukne ili lockuje. Sve dok ne pises nista u te kolone (a ne pises, jer ti je master na starom do poslednjeg trenutka), imaces neki mali downtime jedne od masina, imaces dosta posla - ali sama aplikacija ce videti konzistentnu bazu sve vreme.

Ovo je inace i jako dobra fora po pitanju index-a. Neki indexi ti ne trebaju na masteru, vec npr. samo na slave-u na koji pustas npr. upite za OLAP (obicno je ovo dedicated slave). Da bi ustedeo I/O, ti mozes da imas taj index samo na tom slave-u. Mozda ce on malo da kasni u replikaciji, ali ako imas up i down periode sajta mozes da obezbedis da nikad ne kasni previse - posebno za OLAP koji relano nikad nema problem dok su podaci tu do npr. jucerasnjih.

Ja jako volim devops metodologiju, zato se i bunim kad tako zovu radno mesto. Ovakve stvari su na primer nesto sto se tesko automatizuje i zahteva malo vise manuelnog rada. Proceduru je, sto ja najbitnije, moguce imati vrlo lepo definisanu, kao neki playbook (ne ansible, vec onaj starinski... dokument u nekom wikiju), ali neke stvari je jako tesko napraviti kroz kod.

Nisam pristalica toga da alter znaci da je baza lose projektovana, najcesce to vidjam kad klijent, posle 6 meseci, shvati da on zapravo ne zeli blog o angus govecetu, vec da to treba da bude prodavnica elektricnih trotineta, jer to je samo par izmena, vi cete sve to kompijuterski.... :D. Ono sto mislim je da relacione baze nisu sustinski pogodne za microservices model rada i nece biti dok se ne obezbedi kompletan decouple same baze na microservices, dok se persistent storage ne decouple-uje od api-ja, i dok storage ne postane, kao sto je za sve ostalo, beskonacno brz. (U praksi sve ispod 1ms je beskonacno brzo... ako trosim maximalno 10,000 IOPS-a u piku, meni je storage od 100,000 IOPS-a beskonacno brz... ).. Kako se to realno nece desiti, jer baza nikad nece biti stateless (ne moze, posao joj je da cuva state - zato je baza), plus ce data uvek biti mnogo, mislim da cemo jos dugo vremena ziveti sa relacionim bazama i njihovim osobinama.....

Naravno, imas uvek alternative, tipa prave big data sisteme, gde sve drzis u fajlovima, sve je schemaless, decoupled... ali ti sistemi imaju brdo svojih problema, jednostavno ne mozes da imas finansijske podatke u parquet formatu fajlova i da radis upite kroz HBase ili Hive - trebaju ti odgovori brzo, trebaju ti indexi, trebaju ti transakcije i lockovanje, to su sve stvari direktno vezane za state - i to je glavni razlog zasto ne mozes da imas sve "moderno".

Entity Framework radi join-ove u sql-u. Mislim da i Linq2sql takodje, ali se ne secam vise.

Pa recimo dodas polje mora da prodje kroz sve redove recimo da postavi default vrednost? Ili Oracle to radi drugacije?

OK, ja to posmatram sa stanovišta DBA i DevOpsa. Ne bi meni taj projektant dugo ostao u firmi da se seti kako mu je u tabeli od nekoliko miliona slogova potrebno da doda not null polje koje bi u 99.9999% slučajeva imalo default vrednost.
Sa druge strane, to se radi tako što se doda null polje koje ima default vrednost, pa da se onda radi BULK UPDATE, recimo po hiljadu slogova, a na svakih hiljadu slogova da ide COMMIT. Kada se prođe kroz sve slogove, onda se ponovo promeni polje, da bude not null.

Sve to se lepo začini sa time da se nad tabelom napravi view koji null nad poljem pretvara u default vrednost ( funkciojom nvl - nvl(ime_polja, default_vrednost) ), a nad pogledom se postavi instead of trigger koji hendluje pokušaj upisa null u to polje.

Nije ti se nikad desilo da korisnik posle nekog vremena kada je već odavno baza u upotebi i napunjena je traži neku dodatnu funkcionalnost koja se rešava dodavanjem nekih kolona u tabelu?

Opet ti kažem, ja to gledam kao DBA.
Šta dobijaš time što si dodao NAKNADNO polje za koje si smislio da treba da bude not null? Dobijaš samo da ti baza radi proveru, a to lepo možeš da delegiraš i na aplikaciju.
Recimo, ja vrlo retko koristim FOREIGN KEY constraint. On ti samo usporava upis i brisanje, a ne ubrzava ništa. Više smeta nego što koristi.
Sa druge strane, gomila "developera" i "programera" očekuju da im neki alat automatski generiše šemu baze, SQL, generiše aplikaciju na osnovu toga koje su ti tabele povezane FK relacijama. Ja takve loše programere zovem "Windows" programeri, mada sam čuo za dvojicu koji to rade i na Linuxu.

Ma ne treba ni indekse da koristiš, ni normalizaciju, sve to može aplikacija da uradi. Tako rade pravi programeri :)

Posao baze podataka je da obezbedi integritet baze podataka. Ako je not null pravilo nad bazom onda se baza time mora i baviti.

Toliko muke oko jednog polja. Vise vremena ces utrositi baveci se tom gimanstikom nego pustiti jedan alter. Mislim cemu baza? Sve moze da se odradi sa fajlovima...

Potpuno se slazem. Baza je tu da se sacuvaju $$$ inzenjerskog vremena.

Sreca nasa pa se ti ne pitas ko ostaje u "firmi". Mozes sad na bis da objasnis i kako je Web Application Firewall gubljenje vremena, sto glupi i lenji programeri ne garantuju da nece imati nijedan SQL Injection u kodu? :)

Ajmo polako :

- DevOps kao metodologija proistice iz Agile-a i Lean Manufacturing-a, tj. iz automobilske industruje, tamo, koliko se secam, kraja sezdesetih godina proslog veka. Cilj metodologije je bas veliki broj promena :). Samim tim, ovo sto ti pricas nema veze sa metodologijom - jedino ako si ti od onih koji sami sebe zovu tako... ;)

- Poslovni zahtevi se menjaju. Na zahtev klijenta, zbog compliance-a, jer se promeni neki propis.... Treba li programer da zna kako ce se menjati zakon? Ko treba da predvidi ako klijent hoce da od bloga o leopardima napravi prodavnicu mobilnih telefona? :)

- Constraint, Foreign key i sve ostale metode dodatne provere i te kako imaju svoje mesto u produkciji. Je'l ti stvarno mislis da si najpametniji, a da su svi koji rade dev u Oracle-u, IBM-u i gde vec glupi - pa to prave? Cekaju da im objasnis ? :) Zapravo, od dobrog DBA se ocekuje da on radi na proverama paralelno sa proverama iz koda, za neke, kriticne, podatke.

- U zavisnosti od aplikacije, nekad je provera u kodu dovoljna. Nekad, kao npr sa finansijskim podacima, imas proveru i u kodu i na nivou baze, i jos po koji put. Da, trosi resurse. I dalje kosta manje nego da izgubis pare ili popijes kaznu od poreske. Ako zafali IOPS-a, odes i trazis jos. Nikad mi se nije desilo da kazem "nemamo resursa da obradjujemo protok novca, jer to radimo pazljivo" i da odgovor bude "radite to malo vise ofrlje, sta proveravate dvaput", ili da bude "pa onda smanjite kolicinu novca koja nam dolazi u preduzece". Nadje se novac za to.

- Alter table u MySQL-u i da je polje null ce presloziti celu tabelu. To je sad sredjivano u MySQL 8 koliko se secam, ali na verzijama do 5.7 je prepakivalo sve i to nisi mogao da izbegnes. Imale su forice tipa pt-online-schema-change, ali si morao da preslozis tabelu. Again, nije se neko "dosetuo da doda polje", nego je promenjen zahtev kako treba da radi softver.

I kako odrzavas konzistentnost podataka ?

Kako održavati konzistentnost?

Evo primera koji ne može da reši foreign key. Imaš tabelu u kojoj jedno polje može da ima vrednost samo ako postoji u drugoj tabeli. I onda ti neko kaže, u drugoj tabeli su vrednosti 1,2 i 3 do 30. septembra, ali posle tog datuma treba da bude 2,3 i 4. Zbog istorijskih podataka ne smeš da brišeš vrednost 1, a moraš da dodaš vrednost 4 u tabelu posle 30. septembra.

Ako ti imaš alat koji ti pravi listu vrednosti "automatski" na osnovu FK relacije, nemaš kontrolu vremenske dimenzije. Aplikacija mora da dozvoli da se, ako se unosi podatak "unazad" dozvoli unos 1 do 30. septembra, a ne dozvoli unos broja 4. Posle 30. septembra dozvoljeni unosi su 2, 3 i 4.

Uslovi mogu da budu i "višedimenzioni" ne tako prosti kao jedan datum. Onda FK postaje više smetnja nego korist. To treba da reši aplikaciona logika.

Imam jako loše iskustvo sa time kako programeri rešavaju exception. Neko bi rekao, ok, neka baza digne exception pa će onda "neko" da reši problem - što je primer tipa programiranja koje ja zovem "brigo moja pređi na drugoga".

Primer iz prakse: dobijam stek greške od stotinak linija - razlog, programer nije napravio validaciju da li polje na ekranu sadrži samo cifre. Poslao je jednom servisu ono što piše u polju, pozvana je druga metoda u kojoj prva nije proverila ulazni parametear, onda treća, ... , desta i onda jedanesta metoda pozove bibliotečku funkciju koja radi konverziju u int i sve pukne. Ili pukne na upisu u bazu zato što je polje number. Lepo što je baza odradila validaciju, ali je greška morala da bude uhvaćena mnogo ranije i bolje hendlovana...

I koliko je takvih primera u celoj bazi, ja bih rekao 1 %.
A ostalih 99 % ces da ostavis na milost i nemilost backend i frontend programera...

Inace, za taj slucaj sto si naveo, ako sam dobro razumeo, se koristi check constraint a ne FK.
A u check constarintu se koristi f-ja u koju teorijski (i prakticno) mozes da stavis logiku za n redova velicine komplikovaniju od te sto si naveo...

Daj nemoj da budeš bukvalista. To što sam ja napisao primer sa tri vrednosti može i drugačije da se napiše.
Šta ako FK pokazuje na tabelu od milon rekorda u kojoj je milion računa. Pa se onda zbog raznih razloga napravi preknjiženje na drugih petsto hiljada računa, pa onda FK pokazuje na tabelu od 1.5 miliona zapisa od kojih milion bolje da nisu tu.

Ne znam da li ste videli ovo na linkedin, komentar na video je: kako junior specialist radi hotfix na produkciju:

Nisam te razumeo ovo za racune, racuni su ovde child strana relacije, mozes s njima da radis sta hoces (dok god ima neki parent rekord, a mora da ima !!!, inace su podaci djubre), ali ajde neka si u pravu, nek su ovde fk smetnja.

A kontraprimeri:
- faktura i stavke fakture
- organizacione jedinice
- currency
- faktura i customer
.....

I u tvojim bazama koliko procentualno imas ovih prvih a koliko drugih primera ?

Ako bi se radilo preko ORM-a... i da ne bude "zagusljivo" a vec pricamo o migracijama koje su sastavni deo Laravela.

Kakve su sanse da se napravi novi kontroler/servis koji bi to radio i ubacio kao job, da ne radi sve odjednom? Figurativno pitam.

Licno imam jedan core PHP projekat koji ima bazu sa trenutno preko 70 miliona slogova. Ako ikad pozelim to da prebacim na Laravel, bice problema.

Nemoj mešati aplikativna pravila sa integritetom baze.

Osnovni zadatak baze je da obezbedi integritet baze podataka. To znači da ona treba da obezbedi da se ne mogu uneti neispravni podaci. Da li su oni netačni nije bitno.

Tek ako se odluči da se i tačnost podataka proverava na nivou baze onda se i to realizuje u bazi.




Generalno je loša praksa na više mesta raditi istu stvar.

Ako se odluči da proveru tačnosti podataka radi baza onda to treba da radi baza.

Ako se odliči da se provera tačnosti radi na nekom višem sloju, onda to radi taj viši sloj.

Ako radiš istu proveru na dva (ili više mesta) onda si se osudio na probleme koji će te zadesiti pre ili kasnije, zato što su pravila sklona izmenama (naročito u knjigovodstvenim aplikacijama).

U savremenoj praksi, tačnost podataka se najčešće proverava na nekom sloju iznad baze (ili čak na više slojeva zavisno o kakvim proverama se radi). Razlog je praktičnost. Savremeni zahtevi su često takvi da se pravila tačnosti često menjaju, dinamična su i čak ih često korisnik može i sam podešavati. Sve to je mnogo komplikovanije realizovati na samoj bazi i mnogo je lakše uraditi u aplikaciji.

Ako imas samo jedan database server, nekako je moguce. Ako imas slozenu replikacionu semu, onda moras da imas alat koji upravlja replikacijom, koji ima API sa kojim mozes da se povezes sa kontrolera... Verovatno je moguce, ali ja to nisam radio. Iskreno, dovoljno je retko da ne moras da radis.

U svakom slucaju, ti mozes da napravis servis koji ce da uradi alter table i prebaci sve kako valja, ali da taj servis to radi koristeci migracije mislim da ne mozes. Bukvalno bi morao da override-ujes ceo mehanizam migracija da bi ga naterao da to tako radi... Ne znam da li ti se isplati, bukvalno ces prepraviti pola eloquent-a. :) Po meni onda lakse da batalis eloquent i predjes na cist PDO - neki moji developeri tako rade.

Generalno si u pravu, ja sam naveo primer koji sam imao u praksi da se proverava na dva mesta. Ne bas ista stvar, baza je proveravala integritet i konzistentnost, a aplikacija neku biznis logiku. Nije bila racunovodstvena aplikacija, ali recimo da je baza proveravala, ajde najblizi analog, kao da ne mozes da upises izmenu na kartici, ako nisi prvo uneo fakturu ... tako nesto.

Poenta je da provera na nivou baze nije, i ne treba da bude smatrana losom, posebno ne za kriticne poslove.

To su različite provere i rade se na mestima gde je to logično. Ono što ne valja je raditi istu proveru na dva mesta.



Daleko bilo da je loše.

Ni ja ne smatram da je provera na nivou baze loša.
Poenta je, da između toga da mi 24/7 aplikacija bude 12 sati ugašena zato što treba da se doda not null polje lošija opcija od toga da se to polje doda kao null. A da se kontrola da li je polje popunjeno radi u aplikaciji.
Više volim da mi aplikacija vrati grešku PRE nego što baza vrati exception.

Uvek možeš da napraviš novu tabelu u koju ćeš da staviš dodatno polje i zatim napraviš 1:1 vezu sa osnovnom tabelom.

Ali ne mozes da na primer dodas index bez altera, a mysql 5.7 (i stariji) ce ti i za to lockovati tabelu....

Da se razumemo, kapiram ja sve. Naravno da je bolje nova tabela. Naravno da je alter generalno losa ideja. Ali to je teorija, ja nekad samo dobijem task "pusti alter", pa sta sad? Nekad taj alter menja dve nedelje programiranja, a nekad resava problem performansi - i bolje da odvojim dan da ga pustim, nego da resavamo drugacije. Niko ih ne trazi "eto tako" ili iz dosade, svi koji rade 10+ godina znaju sve ovo... (a task za alter necu, naravno, da primim od juniora, bez da mu ga neko odobri, je'l) . Ali opet, nekad mora.

Primer sa poljem je banalan, obicno se dosta toga izmeni, sto ne mozes sve pokriti u aplikaciji a da ne napravis jos bagova... inace baza koja ne restruktuira rekorde nakonm izmene mora
da splituje, pa onda dolazi do slabiojih performansi zbog toga, samo razmisljam...

@Bane:

To kako radi storage engine unutra, kako odrzava strukturu i indexe... to je prica za sebe. InnoDB source je uglavnom javan (bar dobar deo istog), ti znas da ga analiziras ako te ne mrzi. Cela ta BTree zavrzlama, pa jos spustena na konkretnnu implementaciju matematike je previse za mene. :) Znam da je dr. Tuuri expert za te stvari, znam da bi InnoDB trebalo da bude jezivo dobra implementacija teoretski gledano. Takodje znam da Postgre radi neke stvari bolje, i da ima neke specificnosti koje MySQL nema, par puta sam probao i Toku engine u MySQL-u, za neke stvari.... ali sve je to previse slozeno za mene. :D Vodi racuna, baza nije samo storage engine, ima mnogo u optimizeru, nacinu na koji se bira execution path, kako se koriste indexi.... Oracle koji spominju je tek show, oni imaju neke columnar storage fore direktno, da se koriste paralelno.... ali sa njim nemam puno iskustva.

Pazi sta je jos problem :

- Dodam na tabelu jos jedno polje, recimo CHAR(64). Kratko neko polje, recimo za neki text...
- Baza to doda samo u opis tabele, ne menja strukturu na disku
- Svaki sledeci insert mora da promeni nacin upisa tih npr. 1000 polja koje si radio bulk update. Realno, da ih procita i onda upise negde drugde na disku.

Na kraju imas haos po disku... OK, SSD-ovi nisu toliko osetljivi na fragmentaciju kao ovi od rdje, ali ja nemam blage kako BTree strukture trpe te vrste fragmentacije, kako sve to radi... Jeste, dobices na kraju isto i izbegao si lock, ali me zanima kakve su posle performanse. Dok su bili spinning rust diskovi, ovo deluje da nije bilo srecno resenje....

Takodje, ako se ja secam, Oracle RAC je shared storage arhitektura, sta se desava sa MS SQL-om ili nekom drugom shared nothing bazom, koja ima replikaciju master-slave? Kako se to na njima radi? Deluje mi da tu tek imas problem....

I sta se desava kad pustis ALTER da doda index? To isto ide bez lockovanja? Kad index postaje dostupan? Koliko ti dodavanje indexa na tabeli od 50M ili 500M slogova kosta? Sve i da nemas nominalan lock tabele, kako ti se ponasa DB engine? Pojede li sve postoje iops-e dok podigne index?

Alter nikad nije bezbolno i lako resenje.... ajde se ne lazemo. :D

A kako bi bilo na dev/staging serveru da se odradi kloniranje baze, ista da se alteruje, potom da se lupi kratak downtime gde ce se proveriti timestampovi (nadam se da se koriste u ozbiljnijim stvarima) i gde god postoji izmena posle kloniranja baze da se radi update? Downtime bi trebalo da je DRASTICNO kraci od kompletnog alterovanja jer se ne radi u deployment fazi vec se samo "preveze" baza i potom sa malim downtime-om aplikacije sinhronizuju podaci? Tada realno bilo koga boli q za IOPSe jer u delu kada se najveci deo baze klonira bice 90-95% posla, posle ostaje samo kratak deo.

DB server sa onih mojih 70mil slogova ne moze da radi na HDD normalno, najcesce zbog konstantih SELECT i UPDATE, mislim da imam neku temu od ranije gde sam pitao za savet za to jer sam razmisljao o prelasku na MSSQL. SSD u mom slucaju je obavezan. Mada mislim da se radi i mnogo, mnogo kesiranja pa se SSDovi i ne akaju preterano.

"mislim da imam neku temu od ranije gde sam pitao za savet za to jer sam razmisljao o prelasku na MSSQL"

To sam i ja pitao, i ispalo je da se ne isplati :P

"Onda uradiš još jedan query gde setuješ default ali tada se tabela ne zaključava."

To moze samo ako ti to polje ne treba, sto nece biti slucaj... ako aplikacija podrazumeva da je setovana
defaultna vrednost puci ce, a ako ne nego proverava dal je NULL, onda i ne moras da setujes. No ovo
je banalni primer kao sto sam rekao...

"ali ja nemam blage kako BTree strukture trpe te vrste fragmentacije, kako sve to radi."

btree se koristi za indeks disk strukture bas zbog toga sto je cache friendly. No rekordi ako nisu sekvencijalni
tu ce da bude jurenja po disku sto ce svakako dosta usporiti citanje. SSD takodje trpi ako nisu sekvencijalni.
Recimo imas ociglednu razliku kod random i sekvencijalnog citanja i u RAM-u, kamoli SSD-u ;)

evo ti razlike u performansama kod btree-a i razlicitih binarnih stabala u RAM-u


Znaci smo iteracija kroz btree je 10 puta brza od binarnog stabla.

Milione redova treba ocekivati u "transakcionim" tabelama, zar ne, koje bi po nekom ps-u trebalo da imaju fk ka drugim tabelama, znaci nekoliko INT-ova. Mislim da su tu promene strukture relativno retke u odnosu na ostale tabele, gde se nalaze stvarni podaci. Eventualne promene seta atributa treba ocekivati nad tim "drugim" tabelama i one su bezbolne.

EAV model koji je spomenut, mozda sam video u MS CRM/Dynamics, bem li ga, taj model sam primenjivao na deo ERP baze, ako se secam na dodatne atribute za Proizvod i Komitenta, ali nikako kao resenje za celu db. Kada su promene ceste, a relacioni model moze da se izbegne, vredi razmisliti o document bazi, npr Mongo DB. Ipak moje skromno misljenje je da je rdbms nadmocno resenje za vecinu data poslova .

Da, na MySql-u 5.x, alter lock-uje Master, a zatim i Slave kada krenu event-i za replikaciju. E sad mi smo u nasoj glavnoj app roknuli MSMQ sistem, konkretno MS Mesaging Queue, njega umetnuli pre crud akcije, sto nam je nebrojeno puta spasilo dan. To je bilo krpljenje zvakom, koje drzi vodu vec godinama, ali pravo resenje jeste neki krsteni Cache sistem na osnovu Redis-a. Ako ima dovoljno RAM-a da drzi crud operacije u queue par sati do jednog dana, onda je alter ok.

Ja sam vec pisao, bas na ovoj temi: Produkciona baza ima 3+ servera, uradi se prvo ALTER na slave-ovima, pa se proglasi slave za master i onda pusti i na njemu. :) Slicna logika.

Poenta nije da ne moze da se pusti alter u produkciji (moze), poenta je da ne moze kroz migraciju. Nije RDBMS vnogo, nego ORM :)

Skoro smo pricali na drugoj temi: Kupindo, ako odes na sajt, pise da ima 2 miliona predmeta. To nije 2 miliona redova u transakcionim tabelama, to je dva miliona u tabeli koja drzi predmete, a relacione tabele koje drze veze izmedju atributa i vrednosti imaju, logicno, vise.... ne ulazim u detalje jer ih znam, a poslovna su tajna, ali ako otvoris cipele videces da imaju broj cipela, duzinu gazista, materijal i boju na primer.

A imam sad klijenta cija MySQL baza je veca desetak puta od one na kupindu. :)

Ok, mozda sam terminoloski neprecizan, mislim da su predmeti(ili oglasi) transakciona tabela i imas n:m relationship sa proizvodima ili sta vec a one sa atributima i vrednostima, sto je EAV model, ako razumem. Osim ako se ne radi alter nad predmetima i/ili veznim tabelama, mislim da nemas problem.
Moje zapazanje se odnosilo na jednostavan slucaj da proizvodi sve atribute drze u svojoj tabeli, znaci nemas tabelu atributi, tako ce tokom vremena biti ceste potrebe da se dodaju nove kolone u tabeli proizvodi. Tu se ne radi alter nad milionima redova ?

Ne radi se tu, radi se na nekim drugim tabelama. :D Nije sve EAV, ima mesta gde je nasledjen los kod, gde je nasledjen los dizajn, gde je vise podatak u jednoj tabeli... Na primer :

https://blog.limundograd.com/2...undo-porodica-400-000-clanova/

To je 2013, ako pretpostavis da je tabela koja drzi korisnike sa autoincrement ID-em, zakljucices da tabela ima preko nekoliko clanova vise. :D