Стандартні таблиці Dataverse та віртуальні таблиці: коли варто припинити копіювати дані

By Mirko Peters · 2026-08-22

Порівняння стандартних таблиць Dataverse і віртуальних таблиць. Дізнайтеся, коли варто припинити копіювати корпоративні дані та натомість забезпечити живий доступ до зовнішніх систем.

Automatically translated with AI from the original post. Read the English original

Вибір між стандартною таблицею Dataverse і віртуальною таблицею визначає, наскільки ефективно ваш бізнес працює із зовнішніми даними. Стандартні таблиці зберігають записи безпосередньо в Dataverse, тоді як віртуальні таблиці забезпечують живий доступ до зовнішніх ERP-, складських або фінансових систем, усуваючи ризикові нічні завдання синхронізації та застарілу інформацію.

Головне

• Стандартні таблиці Dataverse постійно зберігають записи локально, тоді як віртуальні таблиці відображають актуальні записи, які отримуються з зовнішніх джерел на запит.
• Використання віртуальних таблиць усуває потребу в нічних завданнях синхронізації, через які відділи продажів ризикують працювати із застарілими даними про залишки на складі.
• Архітектурні рішення мають враховувати насамперед те, де насправді належать ключовий бізнес-процес і управління життєвим циклом записів.
• Продуктивність, дозволи безпеки та можливості фільтрації на віртуальних таблицях працюють інакше через залежність від зовнішніх даних.
• Організації можуть зменшити навантаження на сховище та дублювання даних, підключивши користувачів безпосередньо до авторитетних зовнішніх застосунків через Dynamics 365.

Архітектурна дилема: сховище чи доступ

Під час впровадження Microsoft Dynamics 365 або власних застосунків Power Apps архітектори постійно стикаються з принциповим питанням дизайну: чи варто копіювати зовнішні дані в Dataverse, чи залишити їх у рідній системі та побудувати міст до них? Упродовж багатьох років типовою відповіддю було реплікування. Організації планували нічні інтеграційні процеси, щоб переносити каталоги товарів, залишки на складі та історію рахунків безпосередньо в Dataverse, аби користувачі мали доступ до всього в одному місці.

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

Порівняння стандартних і віртуальних таблиць

Розуміння операційних відмінностей між стандартними таблицями Dataverse і віртуальними таблицями допомагає визначити, коли застосовувати кожну архітектуру. Ця відмінність значно глибша за технічну семантику: вона визначає володіння системою, робочі процеси користувачів і обсяг обслуговування.

Стандартні таблиці Dataverse

Стандартні таблиці, такі як Accounts, Contacts і Opportunities, є рідними елементами екосистеми Dataverse. Dataverse створює таблиці бази даних, керує фізичним сховищем, застосовує моделі безпеки на рівні таблиць і нативно виконує бізнес-логіку, плагіни та робочі процеси над записами. Коли користувач створює або оновлює запис, остаточним авторитетом є Dataverse. Рівень застосунку та рівень зберігання повністю уніфіковані.

Віртуальні таблиці

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

Оцінка операційних компромісів і обмежень

Віртуальні таблиці вирішують проблему синхронізації, але водночас створюють унікальні обмеження, які розробникам і адміністраторам варто ретельно оцінити. Оскільки базові дані не зберігаються в Dataverse, деякі можливості платформи поводяться інакше, ніж зі стандартними таблицями.

Розширений пошук, складні серверні плагіни, поля зведених підсумків і фонові асинхронні робочі процеси можуть поводитися непередбачувано або взагалі не працювати, якщо вони припускають, що дані зберігаються локально. Крім того, продуктивність безпосередньо залежить від стану та швидкості відгуку зовнішнього API або джерела даних. Якщо зовнішня ERP- або складська система працює з затримками чи стає недоступною, відповідні віртуальні таблиці в Dynamics 365 зависатимуть або видаватимуть помилки з'єднання.

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

Висновок

Вибір між стандартними таблицями Dataverse і віртуальними таблицями зрештою залежить від того, хто володіє життєвим циклом даних, і чи потрібне користувачам постійне локальне зберігання, чи достатньо простої контекстної видимості. Якщо зовнішні джерела даних відображати, а не копіювати, організація зможе підтримувати єдиний, чистий робочий простір у Dynamics 365 і не перетворювати Dataverse на безлад із дублікатами таблиць баз даних. Щоб ознайомитися з базовими елементами цього підходу до інтеграції, обов'язково послухайте повний епізод і підпишіться на подкаст, щоб отримувати більше практичних порад щодо хмарних технологій.

Поширені запитання

Чи споживають віртуальні таблиці місце в сховищі Dataverse?

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

Чи можуть користувачі редагувати записи, що відображаються через віртуальну таблицю?

Так, за умови що базовий провайдер даних і зовнішня система підтримують операції запису. Вбудовані провайдери OData v4 та інтеграції Finance and Operations можуть підтримувати дії створення, оновлення й видалення, але зовнішня система все одно застосовує власні правила валідації.

Що станеться, якщо зовнішнє джерело даних стане недоступним?

Якщо зовнішній застосунок або його API стане недоступним, користувачі, які переглядають віртуальну таблицю в Dynamics 365, побачать помилки завантаження або порожні сітки, оскільки запити в реальному часі не можуть отримати зовнішні записи.

Чи є віртуальні таблиці тим самим, що й віртуальні сутності?

Так. Віртуальні сутності – це застарілий термін, який використовувався в старішій документації Microsoft і конфігураціях, тоді як віртуальні таблиці є чинною офіційною термінологією. Базова архітектура та концепції залишаються ідентичними.