die meisten (eigentlich alle) beispiele zu Table-Partitions zielen darauf ab, inserts zu triggern und somit die tupel ihrer Zielpartition zuzuführen.
soweit so gut … dann liegen sie dort - für OLAP lastige anwendungen / DBs ja sehr sinnvoll
ich habe hier aber ein thema, in dem die partition sich je nach “status” eines records ändern könnte. das hiese auch auf updates zu triggern.
das ist ja implementatorisch kein riesiges problem - nur stelle ich mir das hin und herschreiben größerer datenmengen recht aufwendig für die DB vor … um große datenmengen geht es ja - sonst müsste ich ja nicht an partitionierung denken.
der performance-aspekt ist bei mir der kern der geschichte - hmm ich sehe eher dass partitionierung die wartung komplexer gestaltet man hat halt ein paar mehr tables (aber egal)
eine performance-bremse in meinem syschdem ist die ACL für row-level berechtigungen … bis ca 150k-250k records kann man damit arbeiten … es riecht aber danach, dass es mit 1 mio records keine freude mehr macht. da gibts dann halt einen view der rel. aufwendig ist.
daher hab ich mir gedacht (grob umrissen) zwischen private und public oder passiven und aktiven daten zu unterscheiden - wobei die ACL funktionalitaet nur auf die aktiven daten angewendet werden sollen (geringe kardinalitaeten). zu erwarten ist naemlich auch, dass es für den großteil der daten die zugriffskontrolle nicht braucht - weil sie eh “public” sind … in diesem fall brauch das view die ACL nicht hinzujoinen → dat ginge dann fix
bleibt dann nur die frage wie sich das view (union) verhaelt - weil ich auch mit den partitionen eben NICHT direkt auf der master-table arbeite
hmm - und manchmal denke ich - dass ich die partition dafuer garnicht brauche - dann bin ich geneigt den key in den view aufzunehmen - was natuerlich dazu führt, dass ein index begnuegt werden muss.
von der partition erwarte ich, diese einfach dazu mergen zu koennen …