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

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

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

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

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

есть три основных варианта:

  1. unquoted camelCase имена столбцов
  2. процитированный camelCase имена столбцов
  3. имена без кавычек (в нижнем регистре) с подчеркиванием

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

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

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

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

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

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

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

42
camelcasing database-design naming-conventions oop postgresql

2 ответов

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

конвенция в PostgreSQL возникла благодаря сочетанию соблюдения стандартов и долгосрочного опыта ее пользователей. Придерживаться ее.

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

23

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

пример : 

SELECT my_column as "myColumn" from table;
16