Іменування конвенцій для бази даних PostGIS? [зачинено]


11

Ми починаємо створювати базу даних з PostGIS. База даних повинна містити групу з приблизно 5-8 досліджень, які часто працюють з геоданими та статистикою.

Хтось із досвідом іменування конвенцій під час створення бази даних?

деякі важливі речі, які я вже з'ясував, це:

  • використовувати лише малі літери
  • use_underscores не пробіли
  • не використовуйте спеціальних символів, таких як ä, é тощо
  • використовувати лише одну мову (може здатися тривіальною, але ми міжнародна)
  • таблиці назв і стовпців завжди в однині
  • знайти стандартизований спосіб назви об'єктів у базі даних, тобто topic_year_source_format

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

Відповіді:


3

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

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

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

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

BI - Інтер'єр будівлі; БО - Межі; КТ - картографічна; EL - особливості підняття; EM - реагування на надзвичайні ситуації; GE - Геологічний; LT - Освітлення; PG - Сітки сторінки та макети; PL - планіметричний; РА - Растр; RD - Референсне креслення; SI - Поліпшення сайту / підстави; SU - опитування; UT - Утиліти.


1
Це дійсний метод, але я дуже не люблю скорочень. Це, звичайно, питання особистого смаку, але спеціально, якщо ви перебуваєте в міжнародній команді, ці абревіатури можуть бентежити кожного, і кожен завжди потребує словника даних, коли йому потрібно використовувати базу даних. PostgreSQL дозволяє, якщо я не помиляюся, назви об’єктів із 64 букв. Скористайтеся цим простором і створіть найбільш описові імена, які ви можете знайти мовою, яку кожен може зрозуміти.
Джордж Сільва

Мені дуже подобається ідея категоризації даних, і я обговорю це з колегами. І все-таки я не впевнений у назві даних всередині db. Ваші аргументи мають цілком сенс, що для зручності використання краще буде вносити чіткі імена всередині db. Але я побоююся, що документ метаданих може бути менш використаний, як цей. Я думав, що називання даних абстрактними номерами змусить користувачів звертатися до документа з метаданими, і завдяки цьому більше сприятимуть цьому таким чином, щоб люди заповнювали більше інформації метаданих, оскільки їм доводиться посилатися на неї щодня, і документ є вже відкрито ...
Dspanes

@Dspanes, це цікавий аргумент. Як я вже сказав, правильної відповіді немає. Взагалі я не впевнений, що мені подобається ідея зробити назви навмисно заплутаними, щоб змусити користувачів покладатися на метадані ... Хоча це цікава ідея.
Павло

@Paul Так, мені здається, це значить, я знаю;) Але з того, що я відчував дотепер, люди використовують лише те, що для них корисно. Чим корисніше, тим більше вони використовують і чим більше вони використовують, тим краще можуть отримати метадані ... Справа в тому, що у нас немає людини, яка б піклувалася про метадані, тому нам потрібен підхід участі, коли кожен робить свій внесок. Документ з метаданими, можливо, також принесе користь, наприклад, ви можете мати кращі функції пошуку та фільтрування, що дозволяють знайти більш адекватні дані ... але без сумніву, я також роздумую про альтернативні підходи до сприяння участі ...
Dspanes
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.