Size: a a a

pgsql – PostgreSQL

2020 July 30

A

A in pgsql – PostgreSQL
ну для экспериментов совсем без разницы
источник

M

Marat in pgsql – PostgreSQL
Всем привет) В PostgreSQL, если столбец называется user, его же нужно экранировать? Как вы считаете, лучше использовать другое имя столбца или держать в голове, что данное имя зарезервировано и необходимы двойные ковычки?
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Marat
Всем привет) В PostgreSQL, если столбец называется user, его же нужно экранировать? Как вы считаете, лучше использовать другое имя столбца или держать в голове, что данное имя зарезервировано и необходимы двойные ковычки?
лучше избегать зарезервированных слов в названиях объектов базы.
если они встречаются, то сразу возникает мысль, что название не точно отображает хранимые данные.
например user — это login, name, fullname, …? или date — дата создания, обновления? и дата ли там, может там timestamp?
источник

A

A in pgsql – PostgreSQL
наверное там user_id должно быть
источник

NK

Nikolay Kiselev in pgsql – PostgreSQL
Victor Yegorov
лучше избегать зарезервированных слов в названиях объектов базы.
если они встречаются, то сразу возникает мысль, что название не точно отображает хранимые данные.
например user — это login, name, fullname, …? или date — дата создания, обновления? и дата ли там, может там timestamp?
Если вам не сложно, могли бы вы привести примеры удачных названий?
источник

M

Marat in pgsql – PostgreSQL
Victor Yegorov
лучше избегать зарезервированных слов в названиях объектов базы.
если они встречаются, то сразу возникает мысль, что название не точно отображает хранимые данные.
например user — это login, name, fullname, …? или date — дата создания, обновления? и дата ли там, может там timestamp?
Вот тоже так думаю, но в базе почти все подобные поля (user, job, request) - всё это id и иметь кучу колонок с потсфиксом _id кажется не лучшей идеей
источник

A

A in pgsql – PostgreSQL
нормальная идея, это же дейстительно id чего-то
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Nikolay Kiselev
Если вам не сложно, могли бы вы привести примеры удачных названий?
это же холиварный топик! я сейчас что-то скажу и половине понравится, половине — нет…
источник

M

Marat in pgsql – PostgreSQL
A
нормальная идея, это же дейстительно id чего-то
Да, наверное придётся так делать((
источник

M

Marat in pgsql – PostgreSQL
Victor Yegorov
это же холиварный топик! я сейчас что-то скажу и половине понравится, половине — нет…
И всё же, чем больше мнений - тем лучше)
источник

A

A in pgsql – PostgreSQL
удачные названия, это когда у тебя в проекте придерживаются одного соглашения.
источник

VY

Victor Yegorov in pgsql – PostgreSQL
я предпочитаю называть таблицы в единственном числе:
- я храню набор сущностей, обращаясь по ключу получаю одну. поэтому единственное число
- в английском некоторые слова меняются, типа child — children, поэтом просто присобачить s в конце не вариант. мне такие скачки в названиях не нравятся
- часто используется формат, когда в таблице есть <table_name>_id как PK, <table_name>_name как имя
т.е. если есть таблица customer, то там будут customer_id и customer_name — проще писать запросы, зная принцип построения таблиц
источник

M

Marat in pgsql – PostgreSQL
Спасибо за ответы!
источник

АЛ

Аггей Лоскутников... in pgsql – PostgreSQL
Victor Yegorov
я предпочитаю называть таблицы в единственном числе:
- я храню набор сущностей, обращаясь по ключу получаю одну. поэтому единственное число
- в английском некоторые слова меняются, типа child — children, поэтом просто присобачить s в конце не вариант. мне такие скачки в названиях не нравятся
- часто используется формат, когда в таблице есть <table_name>_id как PK, <table_name>_name как имя
т.е. если есть таблица customer, то там будут customer_id и customer_name — проще писать запросы, зная принцип построения таблиц
Однако, users - не зарезервированное слово
источник

VY

Victor Yegorov in pgsql – PostgreSQL
про id
- использовать просто id для PK — удобно, ибо коротко
- но когда вы связываете 2 (и более) таблицы, то просто сделать SELECT id уже не выйдет, надо обозначать таблицу
- с другой стороны, писать customer_id долго (да, я ленивый)
- но опять, если у вас customer_id — это PK, и в других таблицах FK называются тоже customer_id — легко джойнить через JOIN USING (customer_id)
источник

DI

Dmitry Igrishin in pgsql – PostgreSQL
Victor Yegorov
я предпочитаю называть таблицы в единственном числе:
- я храню набор сущностей, обращаясь по ключу получаю одну. поэтому единственное число
- в английском некоторые слова меняются, типа child — children, поэтом просто присобачить s в конце не вариант. мне такие скачки в названиях не нравятся
- часто используется формат, когда в таблице есть <table_name>_id как PK, <table_name>_name как имя
т.е. если есть таблица customer, то там будут customer_id и customer_name — проще писать запросы, зная принцип построения таблиц
👍 это true old school.
источник

A

A in pgsql – PostgreSQL
есть команды которые еще префиксы к таблицам и колонкам лепят
источник

A

A in pgsql – PostgreSQL
с типом данных или  с видом таблицы
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Аггей Лоскутников
Однако, users - не зарезервированное слово
ага. но назвать колонку users мне кажется странным (не могу придумать кейс). а таблицы я не люблю так называть.
и потом, всегда возникает дальнейший вопрос: что это за пользователи.
и начинается:
- часть из них по сути clients или customers — это одно
- часть из них операторы системы — это другое
- всем им надо логины в систему — это третье
источник

АЛ

Аггей Лоскутников... in pgsql – PostgreSQL
A
есть команды которые еще префиксы к таблицам и колонкам лепят
Например справочникам. И внешним справочникам
источник