Соглашения об именах для базы данных PostGIS? [закрыто]

Закрыто . Этот вопрос основан на мнении . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы ответить на него фактами и цитатами, отредактировав этот пост .

Закрыто 2 года назад .

Мы начинаем создавать базу данных с PostGIS. Предполагается, что база данных предназначена для группы из 5-8 исследователей, которые часто работают с геоданными и статистикой.

Кто-нибудь сталкивался с соглашениями об именах при настройке базы данных?

некоторые важные вещи, которые я уже понял:

использовать только строчные
use_underscores не пробелы
не используйте специальные символы, такие как ä, é и т. д.
использовать только один язык (может показаться тривиальным, но мы международные)
имя таблицы и столбцы всегда в единственном числе
найти стандартный способ именования объектов в базе данных, т.е. topic_year_source_format

Особенно последний пункт хитрый. Храня мои собственные данные, я понял, что иногда вы получаете огромные имена. Поэтому было бы лучше хранить эту информацию в метаданных, которые легко доступны, вместо того, чтобы делать эти огромные имена, которые могут быть довольно раздражающими.

postgis-2.0 naming-conventions

— Dspanes
источник

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

Я предпочитаю организовывать данные по группам, потому что, как мы все знаем, иногда метаданные просто не заполняются. Я считаю, что встраивание некоторых из самых основных метаданных в соглашение об именах очень полезно.

Для начала я создал электронную таблицу со списком основных категорий данных, которые обрабатывает моя организация, и дал каждому из них уникальный двухбуквенный код. В электронной таблице также есть описание категории и примеры функций, которые можно найти в каждой категории. Эта таблица доступна для всех в моей организации, и я включаю ее вместе с экспортированными данными.

Я начинаю каждое имя с двухбуквенного кода, за которым следует подчеркивание. Конечно, вы могли бы расширить эту идею и включить имя создателей данных. Постарайтесь, чтобы имена были короткими и документировали ваши методы. Вот несколько примеров категорий, которые я использую:

БИ - Строительный интерьер; БО - Границы; КТ - картографический; EL - Особенности фасада; ЭМ - Аварийное реагирование; GE - геологический; LT - Освещение; PG - страницы сетки и макеты; ПЛ - контурная; РА - Растр; РД - Эталонный чертеж; SI - Улучшения сайта / Основания; SU - обзор; UT - Утилиты.

— Павел
источник

Это правильный метод, но я действительно не люблю сокращения. Это, конечно, вопрос личного вкуса, но особенно если вы работаете в международной команде, эти сокращения могут сбить с толку всех, и каждый будет нуждаться в словаре данных всякий раз, когда ему нужно использовать базу данных. PostgreSQL позволяет, если я не ошибаюсь, 64-буквенные имена объектов. Хорошо используйте это пространство и создайте наиболее описательные имена, которые вы можете найти, на языке, понятном каждому.

— Джордж Сильва

Мне очень нравится идея категоризации данных, и я буду обсуждать это со своими коллегами. Тем не менее я не уверен насчет имен данных в БД. Ваши аргументы имеют смысл, что для удобства использования будет лучше давать четкие имена внутри БД. Но я боюсь, что документ метаданных может быть использован не так, как этот. Я подумал, что присвоение данных абстрактным числам побудит пользователей обращаться к документу метаданных и тем самым будет вносить в него больший вклад, чтобы люди заполняли больше метаданных, поскольку им приходилось обращаться к ним ежедневно, а документ уже открыт ...

— Dspanes

@Dspanes, это интересный аргумент. Как я уже сказал, нет правильного ответа. В общем, я не уверен, что мне нравится идея преднамеренно вводить имена в заблуждение, чтобы заставить пользователей полагаться на метаданные ... это интересная идея.

— Пол

@Paul Да, похоже, я имею ввиду, что знаю;) Но из того, что я получил, люди используют только то, что им полезно. Чем полезнее их использование и чем больше они используют, тем лучше могут получить метаданные ... Дело в том, что у нас нет человека, который бы позаботился о метаданных, поэтому нам нужен подход с участием всех заинтересованных сторон. документ метаданных может также принести пользу, например, вы могли бы иметь более эффективные функции поиска и фильтрации, которые позволяют находить более адекватные данные ... но, без сомнения, я также подумываю об альтернативных подходах для стимулирования участия ...

— Dspanes