jigpuzzled Apr 7 2016 at 09:59

Расширенный скелет проекта PHPixie с аутентификацией и админкой

2 min

4.6K

PHP*Website development*

-2

Comments 37

SerafimArts Apr 7 2016 at 10:47

На будущее — не используйте регистр в именах полей, вместо userId желательно именовать поля как user_id. В некоторых реализациях БД регистр не имеет никакого значения и поля, например для пароля (password) «проверочного слова восстановления пароля» (passWord) будут идентичными. Пример конечно же излишне надуманный, но всё же правила хорошего тона и всё такое.

jigpuzzled Apr 7 2016 at 11:23

так в чем проблема? сама БД не позволит создать колонки password и passWord в одной таблице по той же причине

Big_Shark Apr 7 2016 at 13:32

Ну и как минимум все другие орм и фреймверки хотят использовать поля именно с _, тем самым использую такую схему, человек получит геморрой при смене фреймверка.

jigpuzzled Apr 7 2016 at 13:47

ммм, я вот с доктриной всю жизнь кемел кейс использую. «Все» это какие?

Lachezis Apr 7 2016 at 13:38

Правило хорошего тона в SQL базах данных.

jigpuzzled Apr 7 2016 at 13:49

Где такое написано?

Lachezis Apr 7 2016 at 14:04

Ниже написал причину.

ellrion Apr 7 2016 at 13:49

тоже ближе snake_case однако не слышал что это «правила хорошего тона» и знаю много разработчиков которые любят camelCase и в названиях таблиц и в именах полей (и ругаются на Laravel что она по дефолту работает именно со snake_case).

Lachezis Apr 7 2016 at 13:59

Snake_case это case insensitive идентификатор, все ОРМ сейчас экранируют колонки и имена таблиц — так что это не так критично, но если нужно написать запрос руками то с CamelCase возможно придется экранировать идентификаторы в зависимости от настроек базы (Postgres вроде по умолчанию все приводит в lowercase). Это просто удобнее.

jigpuzzled Apr 7 2016 at 14:15

так есть куча полей которые и так придется экранировать по этой логике, например поле «name» и тд. snake_case и camelCase различаются только когда дело доходит к нескольким словам в идентификаторе

Lachezis Apr 7 2016 at 14:22

По какой логике? Поля приводимые к lowercase экранировать не обязательно.

jigpuzzled Apr 7 2016 at 15:34

давай лучше скинь пример запроса где это будет проблемой, а то честно в упор не пойму о чем ты

Lachezis Apr 7 2016 at 15:46

select name, countPurchases from users
что бы это заведомо завелось нужно использовать
select name, "countPurchases" from users.

snake_case отработает с и без экранирования идентификаторов на любой базе.

jigpuzzled Apr 7 2016 at 22:01

попробовал с кавычками и без, все работает

summerwind Apr 7 2016 at 23:25

ближе snake_case однако не слышал что это «правила хорошего тона»

Первая ссылка в google по «sql style guide»:

Use underscores where you would naturally include a space in the name (first name becomes first_name).

ellrion Apr 8 2016 at 06:34

Ну как бы стайлгайд од какого то чувака это не доказательство и не правило хорошего тона. В разных фирмах или сообществах свои стайлгайды. (напомню что я за snake_case, но не против camelCase)

summerwind Apr 8 2016 at 08:25

Я бы не стал называть его просто «каким-то чуваком» =) Я просто привожу в пример реально существующий стайл-гайд, где четко указано использовать «underscore». И я знаю людей и команды, которые придерживаются его (за неимением официального от MySQL или PostgreSQL). По мне, так достаточно нормальный аргумент, если учесть что в поддержку CamelCase я не вижу ничего кроме вкусовых предпочтений отдельных людей.

jigpuzzled Apr 8 2016 at 08:33

Стайлгайд это просто стайлгайд а не правило хорошего тона. По такой логике можно сказать что ваш код на PSR-2 плох потому что он не по стайлгайду Зенд фреймворка.

Если честно я совсем не понимаю что все придрались к именам таблицы и полей, если вам никто не мешает использовать какие-себе хотите. Уже больше 20 комментов, ни один по фреймворку и коду, а все о камелКейсе

Rastishka Apr 8 2016 at 10:32

Так холивар же.

Мне больше нравится этот ответ:
"Being consistent is far more important that what particular scheme you use."

Так что для большего единообразия полей AR и кода лично я выбрал camelCase.

summerwind Apr 8 2016 at 11:03

А я считаю, что каждый язык должен использовать свой style guide. У SQL свой, у PHP свой, у JSON-API свой. У меня был случай, что мне нужно было перенести проект на другой язык. И что мне, всю схему БД менять? Или добавился второй клиент, использующий JSON-API, написанный на языке с другим стилем именования переменных.

Rastishka Apr 8 2016 at 14:41

У меня данные из MySQL базы данных, через Active record на PHP загружаются в объект JS и рендерятся на клиентсайде в HTML5.
Вопрос: какой стайлгайд мне использовать? Или на каждом уровне свой?

PS Использую camelCase на всех уровнях.

summerwind Apr 8 2016 at 14:44

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

summerwind Apr 8 2016 at 10:49

Если, как вы заметили, многие сделали вам замечание по поводу имен полей — так, может быть, действительно что-то не так?

P.S. И да, я считаю, что писать согласно общепринятому для языка стайлгайду — это правило хорошего тона. Для PHP это PSR, для Python это PEP 8, для Javascript это гайд от Airbnb (несмотря на то, что он неофициальный, его придерживаются очень многие).

jigpuzzled Apr 8 2016 at 11:15

так для SQLа какой? Лично я люблю кемелкейс потому что я могу сразу с БД отправлять в джаваскрипт где и так все камелкейсом.

summerwind Apr 8 2016 at 11:25

Так хотя бы вот этот. Это более-менее распространенный, хорошо оформленный стандарт.

сразу с БД отправлять в джаваскрипт

А потом, когда у вас поменяется название поля в БД, вы будете по всему JavaScript-коду его тоже исправлять?
ИМХО, более-менее серьезные проекты должны использовать что-то вроде https://github.com/thephpleague/fractal

Rastishka Apr 7 2016 at 15:22

Всегда было интересно посмотреть список этих "некоторых БД", где проблема с camalCase, ~~чтобы никогда с ними не сталкиваться~~.

SerafimArts Apr 7 2016 at 15:30

sqlite, mysql, наверняка ещё какие-нибудь.

пруф

Lachezis Apr 7 2016 at 15:32

В MySQL кстати флаг есть который вырубает это.

SerafimArts Apr 7 2016 at 18:02

Ну так оттюнить можно по-разному почти что угодно, наставить плагинов, ещё чего-нибудь. Не суть.

Более жизненный пример: Напишет кто-то поле userName с камелкейсом в БД, а внутри самого кода другой человечек будет писать $entity->username, потом окажется что потребуется переезд на новую БД, т.к. этот сервак сгорит к чертям (у меня такое было, когда БД повреждалась, благо реплика была). А там этот флаг стоит и весь код накрылся, догадывайся только почему username не отображается (значение null в популярных AR для доступа к неизвестным полям моделей). Удачной отладки, называется. Ну а в случае выборки SELECT username FROM ... — вообще все запросы накроются, т.к. мол поле username не найдено.

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

jigpuzzled Apr 7 2016 at 22:07

ну уж если говорить о переезде с одного конфига на другой так тут историй можно еще хуже понапридумывать. Суть проста: большинство БД не чувствительны к регистру, камелкейсу это никак не мешает если писать нормальный код а не «uSerNAme», а если писать фиг знает что то проблемы будут везде

Rastishka Apr 7 2016 at 15:42

Работаю с mysql поля в camelCase и не было проблем.
Вопрос: что я делаю не так?

xstudent Apr 8 2016 at 13:58

В постргесе будут проблемы: Таблицу можно создать как «TeSt1», а попытаться использовать как select * from test1. Будет ошибка «ERROR: relation „test1“ does not exist LINE 1: SELECT * FROM test1»

jigpuzzled Apr 8 2016 at 15:24

так а зачем использовать другое имя?

xstudent Apr 8 2016 at 16:59

В том то и суть, что оно другое только за счет регистра. Масса примеров, когда можно попасть на ошибки. Например, когда код не использует автоматическое заключение в кавычки, или запросы написаны напрямую, Зачем создавать потенциальные проблемы, если можно этого избежать, следуя соглашению о не-использовании в бд кемелкейса?

xstudent Apr 9 2016 at 04:28

P.S. Привычка не-использовать кемел-кейс в моем случае выработалась не в результате чтения код-стайлов, а как раз после многократного выяснения, почему не работает вроде бы правильно написанный код.

Rastishka Apr 9 2016 at 16:37

Ога ога......

Расскажите это разработчикам на JS: согласно code conventions там переменные и функции надо называть в camelCase, а переменные TeSt1 и test тоже внезапно будут разные.

xstudent Apr 10 2016 at 07:23

Простите, а причем тут js? В php и js я тоже за camelCase, но как это связано?