так разработчики работают в ОРМ и используют правило
createdAt
updatedAt
userID
Я считаю, что это не правильно так как в дальнейшем будет куча гемороя с написанием SQL запроса
предлагаю им перейти на правильно
created_at
updated_at
user_id
Но начались какие-то баталии, как переубедить разработчиков? Может вы сталкивались с неймингом и такой бедой?
Спасибо!
Попросите их по телефону прислать запрос в CamelCase
Ну так аргументы Ваши резонны (они же вот тут https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_upper_case_table_or_column_names ), и что тут ещё скажешь? А что говорят они?
на сколько я помню. Когда писал на С/С++/microC -везде использовался формат createdAt updatedAt userID А вот, когда начал работать с СУБД, везде видел так created_at updated_at user_id Ну 1) Сообщество СУБДшников пишет так ( я про _ ) 2) Гораздо удобней смотреть, когда секции/слова отделяются именно _ 3) В СУБД поф*г на регистр ( если не писать " ), поэтому в СУБД вы увидите вместо create tableA - CREATE tablea А потом, когда будете смотреть скрипты на таблицы/функции, чтобы понять, как там всё устроено ( ведь поддержку кода никто не отменял) У вас начнётся головная боль :)
нейминг должен отталкиваться от среды и задачи((
какой ORM они используют если не секрет?
Так среда и задача у них уже не одна (т.е. есть какое-то (какие-то) приложение и отдельно аналитика, как минимум), я правильно понял? Получается, все, кроме основного приложения — "граждане второго сорта"? ;)
ну, типа нам так удобней, а дальше вы уже сами сделаете
есть такое и нашли они сами, просто из-за этого нужно много чего переделывать, а желания нет
Получается, что "вы" — таки граждане второго сорта. ;( Т.е. это уже не технический спор.
Если вы за опцию CamelCase она там есть и её можно как включить как и выключить
))))) ну, как-то так, я просто больше хочу понять, правильно ли то что это нужно отстаивать ?!
да, в этом и проблема, конечно там на 1,5к таблиц, а до 20 штук, но всё равно нужно альтерить и переписывать код
еще появилось мнение, что каждый должен работать в своей удобной среде. Типа разрабы работают вот так, а ты данные потом как хочешь так и забирай, чтобы не нарушать их процесс...
Спросите у них, а представьте себе если бы им питон(тут нужно поставить правильный язык) шаблонный код генерировал код их языка в кодстайле "питона". Им было бы комфортно с таким работать?
Вы не правы tableA нельзя сделать select * from tableA будет ошибка, что такая таблица не найдена будет работать только select * from "tableA"
))))))))) Улыбнуло )
Тогда вас не понял ((
По умолчанию все идентификаторы преобразуются в lower case. Поэтому если написано create TableA (); то можно сделать и select * from tableA; и select * from TABLEA; А вот если вам хочется различать регистр, то надо использовать кавычки
А Вы прямо на их базе отчёты делаете? Или есть ETL в другую? Если последнее, может, в самом деле сойтись на "ты данные потом как хочешь так и забирай" (и "у себя" как хочешь, так и представляй)?
будет ETL Просто если сейчас это займет больше чем 30 мин, тогда будет КАМЕЛ и я уже сам буду обрабатывать . Но хочется ж по правильному )
Пишем вот так, просто и понятно: create table "from" ( "select" varchar(100), "where" varchar(100), "group by" varchar(100), "order by" varchar(100) ); select "select", "where", "group by", "order by" from "from" where "where" = '=' group by "group by", "select", "where", "order by" order by "order by";
Обсуждают сегодня