Подчеркивает или camelCase в идентификаторах PostgreSQL, когда язык программирования использует camelCase?

Это немного беспокоило меня, и я не могу найти решение, которое чувствует right...

Учитывая язык OO, в котором обычное соглашение об именах для свойств объекта является camelCased и примерным объектом, подобным этому:

{
    id: 667,
    firstName: "Vladimir",
    lastName: "Horowitz",
    canPlayPiano: true
}

Как мне смоделировать эту структуру в таблице PostgreSQL?

Существует три основных варианта:

  • Неизвестные имена столбцов camelCase
  • цитирует имена столбцов camelCase
  • имена без кавычек (нижний регистр) с символами подчеркивания

У каждого из них есть свои недостатки:

  • Неупомянутые идентификаторы автоматически складываются в нижний регистр. Это означает, что вы можете создать таблицу с столбцом canPlayPiano, но смешанный случай никогда не доходит до базы данных. Когда вы проверяете таблицу, столбец всегда отображается как canPlayPiano - в psql, pgadmin, объясняет результаты, сообщения об ошибках, все.

  • Цитируемые идентификаторы сохраняют свой случай, но как только вы их создаете, вам всегда придется их процитировать. IOW, если вы создадите таблицу с столбцом "canPlayPiano", произойдет сбой SELECT canPlayPiano .... Это добавляет много ненужного шума ко всем операторам SQL.

  • Имена нижнего регистра с символами подчеркивания являются однозначными, но они плохо сопоставляются с именами, которые использует язык приложения. Вам нужно будет запомнить разные имена для хранения (can_play_piano) и для кода (canPlayPiano). Он также предотвращает определенные типы автоматизации кода, где свойства и столбцы БД должны быть названы одинаковыми.

Итак, я пойман между камнем и твердым местом (и большим камнем, есть три варианта). Что бы я ни делал, какая-то часть будет чувствовать себя неловко. В течение последних 10 лет я использовал вариант 3, но я надеюсь, что будет лучшее решение.

Я благодарен за любые ваши советы.

PS: Я понимаю, где происходит свертывание дела и необходимость кавычек - стандарт SQL, или, скорее, адаптация стандарта PostgreSQL. Я знаю, как это работает; Меня больше интересуют советы о лучших практиках, чем объяснения того, как PG обрабатывает идентификаторы.

Ответы

Ответ 1

Учитывая, что PostgreSQL использует нечувствительные к регистру идентификаторы с символами подчеркивания, следует ли изменить все ваши идентификаторы в приложении, чтобы сделать то же самое? Совершенно очевидно. Итак, почему вы считаете, что наоборот - разумный выбор?

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

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

Ответ 2

Если ваши столбцы в PostgreSQL имеют underscores, вы можете поместить псевдонимы, но doule-quotes.

Пример:

SELECT my_column as "myColumn" from table;