Англійська для розробників SurrealDB

SurrealDB поєднує документ, графіку, і реляційне моделювання в один рушій запитів з SurrealQL, що означає, що словник команди має розтягуватися через ідеї з трьох різних світів баз даних одночасно. Плутанина між «посиланням на запис» і «край графа», або обробка «schemafull» і «schemaless» таблиць як взаємозамінних, призводить до помилок моделювання, які важко розв’язати пізніше. Цей підручник містить інформацію англійською мовою, яку використовують під час обговорення SurrealDB з командою.

Ключовий словник

** ID запису ** — унікальний формат ідентифікатора SurrealDB, що поєднує назву таблиці та ідентифікатор (наприклад, user:tobie ), використовується безпосередньо у запитах і як значення першого класу, а не як непрозорий рядок.

• “Зберігати сам ідентифікатор запису як посилання, а не лише сирий ідентифікатор — SurrealDB може переглядати його безпосередньо без додаткової пошукової таблиці.” *

** Посилання на запис (у порівнянні з краєм графа) ** — поле на одному записі, яке вказує безпосередньо на ідентифікатор іншого запису, відмінне від краю графа, який є власним записом, що з’ єднує два інші записи з власними властивостями.

• “Посилання на запис можна використовувати, якщо вам потрібен лише вказівник на автора, але якщо для самого зв’ язку потрібні метадані — наприклад, про те, коли відбувся перегляд — скористайтеся моделлю ребра графіка.” *

** Країна графа (RELATE) ** — запис першого класу, створений за допомогою інструкції RELATE, який з’ єднує два інші записи і може мати власні поля, що дозволяє виконувати запиту на перетин графа. “Використовуйте RELATE для створення wrote краю між користувачем і повідомленням — це дозволяє нам запитувати «хто написав що» як пересування графа замість з’єднання.”

** таблиця з повною схемою проти таблиці без схеми ** — таблиця може використовувати визначену структуру полів (таблиця з повною схемою) або приймати довільні поля на запис (таблиця без схеми), які буде обрано для кожної таблиці, а не для всієї бази даних. “Зробити таблицю orders повною схемою, оскільки її форма стабільна і перевірка важлива, але залишити event_log без схеми, оскільки її поля змінюються залежно від типу події.”

** SurrealQL traversal (graph query) ** — синтаксис SurrealQL для перехідних відносин ( ->wrote->post ), що дозволяє запиту виражати багатоспускові шляхи графів в рядку, а не через декілька з’ єднань. “Замість трьох окремих з’ єднань, ця перехідна операція SurrealQL перенаправляє користувача від публікації до коментаря в одному описі — він читається як зв’ язок, який він описує.”

Звичайні фрази

• Чи має це бути простою записною лінією, чи сам зв’язок потребує властивостей, що означає, що він повинен бути ребром графа?»
• Чи є ця таблиця schemafull для перевірки, або schemaless, тому що форма справді змінюється?
• Чи можемо ми виразити це як пересування графа замість декількох поїздок навколо?»
• «Що таке формат ID запису тут — чи покладаємося ми на те, що він читається людиною?»
• Чи потрібно цьому запиту RELATE, чи достатньо простого зв’язку запису для цього випадку використання?

Приклади висловлювань

Перегляд запиту на звантаження:

• “Ця модель « сподобалося » як булеве поле у статті — якщо вам потрібно знати, кому сподобалося і коли, це має бути ребро графіка з RELATE, а не прапорець.” *

Пояснення рішення про проектування:

• “Ми зробили основні таблиці доменів повними схем для безпеки, але журнал аудиту залишили без схеми, оскільки нові типи подій з’ являються швидше, ніж ми могли б мігрувати схему.” *

Опис події: “Повільний запит не був відсутнім індексом — це були три окремі пошуки, які мали бути одним переходом графа SurrealQL від користувача до замовлення до елемента.”

Професійні поради

• Скажімо “record link” проти “graph edge” точно - розрізнення визначає, чи може відносина нести свої власні дані, і помилка означає дороге перебудування пізніше.
• Під час перегляду вибору схеми, запитайте “schemafull або schemaless, і чому?” — це змушує явний компроміс замість типового, який ніхто навмисно не вибрав.
• Використовуйте “RELATE” як дієслово при описі створення краю — це відповідає ключовому слову SurrealQL і уникає неоднозначності з загальним “з’єднати ці записи.”
• Описувати багатоскакові запити як “переходи”, а не як “з’ єднання” — це сигналізує про те, що ви думаєте у графічній моделі SurrealDB, а не перекладаєте з SQL- звичаїв.

Практичні вправи

1. Поясніть у двох реченнях, коли відносини мають бути ребрами графа, а не простими посиланнями на записи.
2. Написати коментар перегляду коду у одному реченні, у якому рекомендується зробити таблицю повною за схемою.
3. Опишете вашими словами, що робить пересування по графі SurrealQL у порівнянні з з’ єднанням SQL.

Розвиток комунікації: розробка методів комунікації

Унікальний підхід SurrealDB до даних — його здатність безшумно поєднувати документи, ключ-значення і моделі графів в одній базі даних — вимагає точного спілкування. Для людей, для яких англійська не є рідною мовою, просто перекладати терміни недостатньо. Складності професійного дискурсу, особливо навколо проектних рішень, повідомлення про помилки і співпраці, можуть бути неймовірно важко зрозуміти без глибшого розуміння того, як розробники * насправді * говорять про свою роботу. Це не просто знання того, що « схема » є « схемою »; це розуміння того, коли і чому ви використовуєте конкретні фрази, пов’язані з моделюванням даних, оптимізацією запитів або потенційними конфліктами в базі даних. Поширена проблема виникає при обговоренні змін - особливо в сценарії перегляду коду - де відсутність ясності може призвести до непорозумінь і марних зусиль. Наприклад, замість того, щоб сказати « Цей запит повільний », ефективнішим підходом буде « Я спостерігав, що цей запит має підвищену затримку під час пікового використання; чи можемо ми дослідити оптимізацію стратегії індексування або розглянути альтернативні методи отримання даних? » Це демонструє не лише проблему, але й спробу спільно вирішити її. Аналогічно, при описі змін в Pull Request, заява «Я оновив схему» є неясною. Яскравішим описом буде: «Ця PR вводить нове поле, user_preferences, до схеми документа users, щоб вмістити специфічні для користувача параметри, вирівнюючи з розвитком вимог до персоналізованого досвіду»

Інша часто зустрічається проблема полягає в вираженні складних відносин між елементами даних під час обговорення графічних запитів. Фрази на кшталт «пересування по краях» або «кардинальність відносин» можуть звучати абстрактно без твердого ґрунту в тому, як вони пов’язані з продуктивністю і цілісністю даних. Важливо вийти за рамки буквальних перекладів і зрозуміти намір за цими термінами. Наприклад, пояснення того, що «оптимізація пересування країв для часто доступних відносин» є життєво важливою для поліпшення швидкості запиту, вимагає не тільки технічної дії, але і її впливу на загальну ефективність системи. Крім того, конструктивна критика в перегляді коду потребує обережного формулювання - уникати обвинувальної мови, наприклад, « Це неправильно », а замість цього вибрати описи, такі як « Я помітив, що цей запит може отримати користь від використання індексу для поліпшення продуктивності. » Це переносить фокус на вирішення проблеми, а не звинувачення.

Нарешті, пам’ятайте, що активне слухання і запитання прояснюючих питань є найважливішими. Не вагайтеся ввічливо запитати про подальші пояснення, якщо щось не зрозуміло; такі фрази, як « Чи можете ви розібратися, що ви маєте на увазі під …?» або « Чи можете ви надати приклад того, як це буде використано?» демонструють справжні зусилля зрозуміти контекст і ефективно внести свій внесок до команди. Цей активний підхід сприяє більш інклюзивному і продуктивному середовищі комунікації, зменшуючи потенційні непорозуміння і сприяючи співпраці через мовні бар’єри.

// Example: Creating a simple graph edge
db.vertices.insert({name: "Alice", type: "user"});
db.edges.insert({from: "Alice", to: "Bob", relation: "knows"});