Хтось, хто використовує HierarchyId у реальному виробництві з таблицями розумного розміру, більше кількох тисяч рядків? Це надійно / ефективно? До сих пір я не знайшов нікого , не зв'язаний з продавцем рекомендувати його, і Пол Нільсен радить проти нього тут .
Який ваш досвід використання HierarchyId у фактичних виробничих системах?
Якими критеріями ви користувалися, коли ви обирали HierarchyId над його альтернативами?
Відповіді:
Я реалізував HierarchyID і виявив, що він забезпечує хорошу продуктивність і простий у використанні.
Я використовував його на відносно невеликих наборах даних (десятки тисяч рядків) з ієрархією до 10 гілок глибиною.
Навіщо його використовувати? Тип HierarchyID пропонує ряд допоміжних методів (таких як IsDescendantOf), які полегшують вашу роботу, ніж прокручування власного матеріалізованого шляху.
Коментар Пола Нільсена щодо StackOverflow мене бентежить - ієрархія ID - це матеріалізований шлях. Я більше схильний погодитися з цим коментарем нижче його відповіді.
Кращим питанням може бути "чому б не використовувати його". Він простий у використанні, забезпечує безліч функціональних можливостей, які ви інакше писали б для себе, і працює добре (в моїх обмежених тестах).
Це відповідь на питання Кірка "чому б не використати його (HierarchyId)". У порівнянні з матеріалізованим шляхом, у деяких важливих випадках HierarchyId здається менш ефективними та менш зручними для роботи.
Причина проста: цитуючи коментар Microsoft щодо Connect , "Проблема полягає в тому, що виклики CLR, включаючи методи ієрархіїID, непрозорі для оптимізатора запитів. Це задумано. Однак це означає, що оцінка їхньої простоти іноді може бути досить неправильно ».
З іншого боку, реалізувати матеріалізований шлях дуже просто, перший раз, коли нам це потрібно зробити, а наступного разу це по суті завдання копіювання та вставки. Таким чином, ми отримуємо більш універсальне та ефективніше рішення з дуже невеликими зусиллями.
Тож я повністю погоджуюся з Полом Нільсеном, який у своїй чудовій книзі під назвою "Microsoft® SQL Server® Біблія 2008" написав так: "Новий Ієрархій не без суперечок. Він новий і отримує багато часу для преси та демонстрації, але я" я не впевнений, що це проблема, яка потребувала іншого рішення ".
Моя компанія використовує HeirachyID при прямих продажах, багаторівневому маркетинговому програмному забезпеченні. Це працює. Я насправді не робив жодної роботи з цим, я просто знаю, що ми його використовуємо.
Найбільша проблема, яку я бачив з цим, полягає в тому, що ми повторюємо рівні через циклічний спосіб, а не на більш наборі. У цій області він не дуже хороший для нас, але я не впевнений, чи це проблема з типом або нашою реалізацією цього.
Одна з проблем ієрархії полягає в тому, що ви заблокували постачальника. Але я знайшов чудову статтю Адама Мілаццо про те, як все працює внутрішньо:
http://www.adammil.net/blog/view.php?id=100
Завдяки цьому я зміг написати сценарій Postgres для перетворення набору даних із MSSQL. Також включив його до сценарію, який я написав для імпорту бази даних AdventureWorks у Postgres:
https://github.com/lorint/AdventureWorks-for-Postgres
Просто знайдіть там "hierarchyid" у файлі install.sql, і незабаром ви знайдете посилання на його перетворення.
Наша команда реалізувала це у виробництві, спочатку продуктивність хороша, через 2 роки таблиця містить 430 000 рядків, а getroot і getdecendent займає 3 секунди, обидва вони потрібні для обчислення наступного значення id для вставки запису. Тепер одна вставка піддерева займає близько 16 секунд, що зовсім не прийнятно.