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

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

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

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

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

unquoted camelCase column names quoted camelCase column names unquoted (lowercase) names with underscores

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

Unquoted identifiers automatically fold to lowercase. This means that you can create a table with a canPlayPiano column, but the mixed case never reaches the database. When you inspect the table, the column will always show up as canplaypiano - in psql, pgadmin, explain results, error messages, everything.

Quoted identifiers keep their case, but once you create them like that, you will always have to quote them. IOW, if you create a table with a "canPlayPiano" column, a SELECT canPlayPiano ... will fail. This adds a lot of unnecessary noise to all SQL statements.

Lowercase names with underscores are unambiguous, but they don't map well to the names that the application language is using. You will have to remember to use different names for storage (can_play_piano) and for code (canPlayPiano). It also prevents certain types of code automation, where properties and DB columns need to be named the same.

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

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

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