Mogući problemi sa performansama sledećeg rešenja?

[Ilija Studen]

U activeCollabu svi objekti koji pripadaju projektu (taskovi, milestonei, poruke, fajlovi itd) dele neka zajednička svojstva:

obavezna:

- project_id
- parent_id
- name
- body
- visibility
- created_on
- created_by_id
- updated_on
- updated_by_id
- version
- position

samo za assignable objekte:

- due_on
- priority
- assignee_id
- resolution
- resolved_on
- resolved_by_id

Jedno rešenje koje mi je palo na pamet je da koristim inehritance mogućnosti ORM-a (Doctrine) i sve project objekte smestim u jednu tabelu. Dakle, da se odlepim od one table one class principa i sve project objekte smestim u jednu tabelu s tim da se razmikuje tip.

Znači, ta tabela bi imala sva navedena polja uz dodatak ID i TYPE_ID polja. Ono što me interesuje je koliko velike tabele (sa dosta polja i relativno velikim brojem upisa) utiču na performanse? Kada kažem relativno velika mislim na situaciju u kojima jedna klasična web aplikacija može da se nađe (do milion recorda recimo). Kako takva tabela scaluje (10K recorda, 100K recorda, 1M recorda itd)?

Kontam da ne bi smelo biti problema ako dobro rešim indekse i ne izvlačim sve kolone kada mi nisu potrebne. Pošto je InnoDB requirement nema table lockinga tako da je i rad sa celom tabelom oslobođen čekanja.

Razlog zašto mi se ovo rešenje izuzetno sviđa su agregacija podataka i mogućnost kreiranja složenih izveštaja: "Daj mi sve nerazrešene zadatke (taskovi ili milestonei) koji su assigneovani Iliji ili njegovoj kompaniji u tom i tom projektu, a pri tom pripadaju Feature requests listi i nisu markirani kao draft ili private i grupiši ih po prioritetu". Krajnji benefit je za korisnike: uz dobar interfejs activeCollab bi mogao imati strašno moćan reporting engine - definitivno jedan od boljih među dostupnim web rešenjima.

Interesuje me samo MySQL, 4.1+ with InnoDB support.