Oracle
 sql >> база данни >  >> RDS >> Oracle

Кога трябва да използвам Index Organized Table на Oracle? Или кога не трябва?

По принцип организираната по индекс таблица е индекс без таблица. Има обект на таблица, който можем да намерим в USER_TABLES, но той е просто препратка към основния индекс. Структурата на индекса съответства на проекцията на таблицата. Така че, ако имате таблица, чиито колони се състоят от първичния ключ и най-много една друга колона, тогава имате възможен кандидат за ИНДЕКС ОРГАНИЗИРАН.

Основният случай на използване на организирана по индекс таблица е таблица, която почти винаги е достъпна чрез нейния първичен ключ и ние винаги искаме да извлечем всички нейни колони. На практика организираните по индекс таблици най-вероятно са референтни данни, афери за търсене на код. Таблиците на приложенията почти винаги са организирани на куп.

Синтаксисът позволява на IOT да има повече от една неключова колона. Понякога това е правилно. Но това също е индикация, че може би трябва да преразгледаме дизайнерските си решения. Разбира се, ако открием, че обмисляме нуждата от допълнителни индекси на колоните с непървичен ключ, тогава вероятно ще бъдем по-добри с обикновена таблица с купчина. Тъй като повечето таблици вероятно се нуждаят от допълнителни индекси, повечето таблици не са подходящи за IOT.

Връщайки се към този отговор, виждам няколко други отговора в тази тема, които предлагат пресечни таблици като подходящи кандидати за IOT. Това изглежда разумно, тъй като е обичайно пресичащите таблици да имат проекция, която съвпада с кандидат-ключа:STUDENTS_CLASSES може да има проекция само на (STUDENT_ID, CLASS_ID).

Не мисля, че това е чугун. Пресечните таблици често имат технически ключ (т.е. STUDENT_CLASS_ID). Те може също да имат неключови колони (колони с метаданни като START_DATE, END_DATE са често срещани). Освен това няма преобладаващ път за достъп - искаме да намерим всички студенти, които посещават клас толкова често, колкото искаме да намерим всички класове, които посещава ученик - така че се нуждаем от стратегия за индексиране, която поддържа и двете еднакво добре. Не казвам, че пресечните таблици не са случай на използване на IOT. просто не са автоматично такива.



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. NO_DATA_FOUND изключение не е хвърлено, когато се използва в SELECT INTO

  2. валидиране на xml документ в java източника на Oracle

  3. Грешка при добавяне на режим на готовност

  4. PLS-00103 създаване на външна таблица с динамичен SQL

  5. Предварително извличане на Oracle JDBC:как да избегнем изчерпването на RAM/как да направим Oracle по-бърз с висока латентност