sql >> Database >  >> RDS >> Oracle

Wanneer moet ik Oracle's Index Organised Table gebruiken? Of, wanneer niet?

In principe is een index-georganiseerde tabel een index zonder tabel. Er is een tabelobject dat we kunnen vinden in USER_TABLES, maar het is slechts een verwijzing naar de onderliggende index. De indexstructuur komt overeen met de projectie van de tabel. Dus als je een tabel hebt waarvan de kolommen bestaan ​​uit de primaire sleutel en maximaal één andere kolom, dan heb je een mogelijke kandidaat voor INDEX ORGANIZED.

De belangrijkste use case voor index-georganiseerde tabel is een tabel die bijna altijd toegankelijk is via de primaire sleutel en we willen altijd al zijn kolommen ophalen. In de praktijk zijn index-georganiseerde tabellen hoogstwaarschijnlijk referentiegegevens, code-look-up-zaken. Applicatietabellen zijn bijna altijd op een hoop geordend.

Dankzij de syntaxis kan een IOT meer dan één niet-sleutelkolom hebben. Soms klopt dit. Maar het is ook een indicatie dat we misschien onze ontwerpbeslissingen moeten heroverwegen. Zeker als we de noodzaak van aanvullende indexen op de niet-primaire sleutelkolommen overwegen, zijn we waarschijnlijk beter af met een gewone heaptabel. Dus, aangezien de meeste tabellen waarschijnlijk extra indexen nodig hebben, zijn de meeste tabellen niet geschikt voor IOT's.

Terugkomend op dit antwoord zie ik dat een aantal andere reacties in deze thread intersectietabellen voorstellen als geschikte kandidaten voor IOT's. Dit lijkt redelijk, omdat het gebruikelijk is dat intersectietabellen een projectie hebben die overeenkomt met de kandidaatsleutel:STUDENTS_CLASSES kan een projectie hebben van slechts (STUDENT_ID, CLASS_ID).

Ik denk niet dat dit gietijzer is. Kruisingstabellen hebben vaak een technische sleutel (bijv. STUDENT_CLASS_ID). Ze kunnen ook niet-sleutelkolommen hebben (metadatakolommen zoals START_DATE, END_DATE komen vaak voor). Er is ook geen gangbaar toegangspad - we willen alle studenten vinden die een klas volgen zo vaak als we alle klassen willen vinden die een student volgt - dus we hebben een indexeringsstrategie nodig die beide even goed ondersteunt. Ik zeg niet dat intersectietabellen geen use-case zijn voor IOT's. alleen dat ze dat niet automatisch zijn.



  1. Een praktische oplossing nodig voor het maken van een patroondatabase (5-5-5) voor 15-Puzzle

  2. Implementeer MySQL-gebeurtenismelding terug naar een Delphi-toepassing

  3. Fout met MySQLdb op OS X El Capitan

  4. Zoek n dichtstbijzijnde buren voor een bepaald punt met behulp van PostGIS?