Чи персональні бази геоданих краще підходять для швидкого запиту індексованих атрибутів, ніж файлові бази даних геоданих?

Я готую дані для програми ArcGIS Engine, яка запитує дані для пошуку адреси. Іноді ми шукаємо просто на полі назви вулиці, просто на полі номера будинку чи на обох. Під час використання персональних баз геоданих або геоданих SDE можна додати індекс атрибутів у кілька стовпців на додаток до одноколонних індексів. З якоїсь причини, згідно зі статтею ESRI створення атрибутів, індекси атрибутів у декількох стовпцях неможливі при використанні файлових баз даних. Вони не згадують, чому це так - можливо, файли баз геоданих їм чомусь не потрібні?

Індекс багато стовпців на полі номера будинку та назви вулиці повинен теоретично покращити ефективність мого запиту при пошуку обох полів одночасно, але чи варто перейти на використання особистої бази даних? У мене є відчуття, що недоліки використання особистої бази даних можуть заперечувати переваги індексу багато стовпців.

У мене склалося враження, що Есрі хоче, щоб ми відійшли від персональних баз геоданих, але чи це випадок, коли особисті бази даних є кращим варіантом? Якщо у вас є досвід з цим, я хотів би знати.

Щоб відповісти на першу частину вашого запитання, я думаю, що це допомагає переглянути додатковий текст у довідковому файлі «Створення індексів атрибутів» про індекси багато стовпців.

Порядок, у якому поля відображаються в індексі багатоколонок, є важливим. У індексі багатоколонок зі стовпцем А, що передує стовпцю B, стовпець A буде використаний для проведення початкового пошуку. Крім того, такий індекс буде набагато кориснішим для запитів, що стосуються лише стовпця А, ніж для запитів, що стосуються лише стовпця B.
Створіть індекс багато стовпців на A і B. Цей індекс, як правило, буде більш ефективним для запитів, що включають обидва стовпці. Для запитів, що включають лише A, цей індекс був би повільнішим, ніж індекс лише для A. Цей індекс буде мало корисний для запитів, що включають лише B. Для компенсації можна створити додатковий індекс на B.

Обидва ці уривки показують, що багатоколонкові індекси краще для спеціалізованого використання. Крім того, використання такого індексу для сортування лише по одному з включених стовпців може насправді пошкодити продуктивність. З цієї причини, ймовірно, будуть потрібні окремі індекси стовпців для кожного з атрибутів, включених до індексу багато стовпців.

Я знайшов посилання на старий, але цікавий документ ESRI із зазначенням 9 причин вибору Файлу через персональний GDB . Він цікавий тим, що він конкретно називає ефективність як одну з причин. Частина цього підвищення продуктивності пов'язана з файловою системою зберігання даних. Я думаю, що це може також зіграти через відсутність підтримки у багатьох стовпцях. На відміну від персонального GDB, який представляє собою єдиний файл, індекс у файлі GDB зберігається як окремий файл у структурі GDB. Це означає, що індексний файл та файл атрибутів для певного класу функцій повинні бути пов'язані та доступні разом. Я міг бачити, де індекс з декількома стовпцями призведе до стрибків назад і назад між файлами індексу та атрибутів і, можливо, спричинить показник ефективності, що переважає над збільшенням ефективності індексації.

Оскільки вже існує значне підвищення продуктивності роботи з File GDB над Personal GDB, впроваджувати індекс багато стовпців, мабуть, не варто.

В моєму досвіді роботи з обома типами GDB я бачив, що персональний GDB працює приблизно на 50% більше, ніж файл. Виходячи з наданих вами даних щодо файлу GDB, якщо ви переходили в PGDB, ви, ймовірно, отримали персональний GDB ~ 300 Мб. З того, що я бачив, робота з базами даних MS Access, як в продуктах ESRI, так і окремо, полягає в тому, що ви починаєте бачити зниження продуктивності після того, як файли ".mdb" значно збільшаться в розмірі понад 100 Мб.

Інша проблема, ймовірно, полягає в тому, що навіть якщо ви зможете прискорити пошук атрибутів, ви побачите велику ефективність, пов’язану з переміщенням у кадрі даних та оновленням представлення даних. Шар просто не малюється так швидко, якби він був у PGDB. Ця стаття, яка порівнює типи баз геоданих, дає більше інформації про відмінності в продуктивності.

Як і в багатьох справах, найкращий вибір, зрештою, зводиться до того, що стосується вашого використання. Якщо ви хочете виконати багато операцій з базою даних, які ви хотіли б виконати, наприклад запити та оновлення, які ви можете робити в інтерфейсі доступу, то персональний GDB може бути кращим. Якщо ви плануєте лише виконати деякі запити, але в першу чергу буде візуалізувати просторові дані, то продуктивність безумовно падає на сторону File GDB.

Існує щонайменше 9 головних причин використовувати File Geodatabase через Personal Geodatabase. На жаль, є ще набагато більше причин, щоб зберегти старий PGDB; ваша дилема бути одним із них. (жодної публікації ESRI на цю тему)

Я вважаю, що основне призначення FGDB над PGDB - це ємність зберігання та продуктивність просторових даних (швидкість малювання, пошук, просторове індексація, просторовий запит тощо), а не функціональність, така як індексні "атрибутивні" множинні колонки та інші розширені функції SQL, які зазвичай є такою невід'ємною частиною будь-якої СУБД. (Що таке PGDB на базі MS Access, а не FGDB, котрий є рідним ESRI) Як бічна примітка; Максимальний розмір файлу бази даних MS Access - 2 ГБ, що також є максимальним розміром будь-якого одного PGDB. На відміну від цього, обмеження розміру файлу FGDB становить 1 ТБ, яке можна витратити на 256 ТБ.

ESRI також заявляє, що: Синтаксис, який ви використовуєте для створення виразу SQL, відрізняється залежно від джерела даних. Це тому, що хоча SQL є стандартним, не все програмне забезпечення баз даних реалізує один і той же діалект SQL. та Для запиту на основі файлових даних, включаючи файли геоданих, покриття, файли форм, таблиці INFO, таблиці dBASE, дані CAD та VPF, ви використовуєте діалект SQL, реалізований в ArcGIS, який підтримує підмножину функцій та функцій, доступних в персональних та Геодані ArcSDE.

Іншими словами (і PGDB і ArcSDE GDB є доказом цього), якщо база даних геоданих, що лежать в основі СУБД, підтримує цю функціональність, то вона повинна бути доступною . Це, ймовірно, ви можете створити індекс багато стовпців у PGDB, який має базу даних MS Access. Те саме з будь-якою базою геоданих ArcSDE з базовою СУБД, яка підтримує цю функціональність.

Що стосується файлу Geodabase ; у 9.2 випуску FGDB ESRI вказував на те, що деякі з цих функцій та функцій можуть бути додані у майбутніх випусках FGDB, цитуючи; "Файлові бази даних не підтримують усі можливості та функції, доступні для персональних баз геоданих. На ArcGIS 9.2 найпоширеніші функції, які не підтримуються файловими базами даних, включають DISTINCT, GROUP BY і ORDER BY, а також задані функції AVG, COUNT, MIN, MAX і SUM не підтримуються поза підзапитами. Підтримка деяких із них, ймовірно, буде додана в майбутніх випусках. "

Через чотири роки у версії 10 жодна з цих функцій і функцій недоступна. ( Список доступних функцій )

Схоже, що FGDB - це незавершене виробництво, і йому потрібні можливості індексації багато стовпців стільки, скільки потрібно всіх необхідних функцій СУБД. Я думаю, що ми будемо застрягати з PGDB, поки розробники ESRI не вирішать, що важливо розширити його функціональність на FGDB.

Відроджуючи цю тему / проблему, я виявив, що поєднувати, де можливо, FGDB та PGDB, може бути корисним. Наприклад, зробити базу даних про подряпини-геодані PGDB значно допомогло виконувати запити. Розмір PGDB не повинен занадто сильно збільшуватися, як зазначено вище.