Программирование[8]

Да, со странами мне кажется не удачный пример, всегда страны в базе хранятся, ну ясное дело не в енам поле)
Вот недавно делал поле "день" enum('Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday') , новые дни никак не добавятся ,  удаляться тоже не будут, в общем идеальная вещь для енам( в рамках моей задачи конечно). Енам сам по себе еще гарантирует целостность данных, ведь если сделать тип varchar,  то есть вероятность что один дебик напишет Thursday, а другой не зная как пишется слово напишет Tursday и где-то вылезет баг

Да, со странами мне кажется не удачный пример, всегда страны в базе хранятся, ну ясное дело не в енам поле)

Вот недавно делал поле "день" enum('Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday') , новые дни никак не добавятся ,  удаляться тоже не будут, в общем идеальная вещь для енам( в рамках моей задачи конечно). Енам сам по себе еще гарантирует целостность данных, ведь если сделать тип varchar,  то есть вероятность что один дебик напишет Thursday, а другой не зная как пишется слово напишет Tursday и где-то вылезет баг

на самом деле почему-то у нас тоже страны в базе хранятся, но я не пойму чем это может быть продиктовано

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

единственное что я могу придумать - более одного независимого сервиса юзают данную бд (что в концепции микросервисной архитектуры дикий рак) - тогда обоснованно

ничто не мешает держать эту же статику в бд в явном виде

 

тем более что я уже писал, на нее сверху наложатся колонки описывающие логику каждого значения перечисления

да и банально текстовый вид, в коде его хардкодить собрался?

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

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

так что хранить статику в бд, это примерно то же самое что сознательно отказываться от типов или использовать duck typing

в большом количестве случаев это менее эффективно

не совсем понял что такое "текстовый вид" 

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

из примера фессника - например тебе придется писать нечто вроде 

if (dayType == "Sunday") 

  naRabotuNeNado()

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

если ты про "description" то это изи кодится используя таплы / дататайпы 

на самом деле почему-то у нас тоже страны в базе хранятся, но я не пойму чем это может быть продиктовано

не совсем понял что такое "текстовый вид" 

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

из примера фессника - например тебе придется писать нечто вроде 

if (dayType == "Sunday") 

  naRabotuNeNado()

 

Да, со странами мне кажется не удачный пример, всегда страны в базе хранятся, ну ясное дело не в енам поле)

Вот недавно делал поле "день" enum('Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday') , новые дни никак не добавятся ,  удаляться тоже не будут, в общем идеальная вещь для енам( в рамках моей задачи конечно). Енам сам по себе еще гарантирует целостность данных, ведь если сделать тип varchar,  то есть вероятность что один дебик напишет Thursday, а другой не зная как пишется слово напишет Tursday и где-то вылезет баг

на самом деле почему-то у нас тоже страны в базе хранятся, но я не пойму чем это может быть продиктовано

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

единственное что я могу придумать - более одного независимого сервиса юзают данную бд (что в концепции микросервисной архитектуры дикий рак) - тогда обоснованно

ничто не мешает держать эту же статику в бд в явном виде

 

тем более что я уже писал, на нее сверху наложатся колонки описывающие логику каждого значения перечисления

да и банально текстовый вид, в коде его хардкодить собрался?

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

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

так что хранить статику в бд, это примерно то же самое что сознательно отказываться от типов или использовать duck typing

в большом количестве случаев это менее эффективно

 

не совсем понял что такое "текстовый вид" 

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

из примера фессника - например тебе придется писать нечто вроде 

if (dayType == "Sunday") 

  naRabotuNeNado()

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

 

если ты про "description" то это изи кодится используя таплы / дататайпы 

 

шо?

в базе таблица с ручной айдишкой == числом и любыми нужными тебе колонками , какие таплы, дататайпы, тебе всё равно придется делать таблицу для этого, так может ее сразу сделать?

целостность в базе гарантируется ключами

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

ормки даже могут автоматическую конверсию делать, я такое на T4 делал на 4 курсе, в EFCore вон наконец из коробки завезли

ну и в худшем случае каст в инт делаешь или что надо

единственный плюс енума в постгре это что тебе и в скле можно будет не писать числа. на этом конец

 тебе всё равно придется делать таблицу для этого, так может ее сразу сделать?

целостность в базе гарантируется ключами

 

ты походу не понял идеи про которую я говорю

зачем делать таблицу для статики? вот пример у фессника - дни недели, зачем мне может понадобиться таблица если я могу просто в коде написать

object Wensday(field1,field2, field3) extends DayOfWeek

и я имею типизированный объект по которому могу статически проверять код по его типу или писать тайп классы и не разводить is instance of которая будет делать что-то в рантайме когда я могу сделать это в компайл тайме

но даже если ваш язык это не позволяет (даже через либы и всякую магию аннотаций или плагинов компилятора) то всеравно даже в тестах это будет работать из коробки + быстрее и не нужно даже думать о том чтобы это хранилось в бд

я просто говорю именно про тот кейс который не требует хранить это в бд (когда это статика)

я уже два раза минимум написал самый банальный пример

у тебя твои дни недели объявлены енумом

ты держишь таблицу ну хуй знает, толкан, где хранится какой юзер в какой день недели и сколько говна из себя выдавил

твоя задача показать историю по юзеру

ты ему что будешь в колонке дня недели выводить? как в енуме и написано?

нахуй ему это сдалось, ему надо текст, где ты его брать будешь?

дальше тебе надо будет поделить рабочие и будние, с таблицей ты просто хуяришь доп. колонку и спокойно делаешь выборку

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

то, что ты будешь выводить и то, что у тебя в базе - это две разные вещи. Ты с api на view отправишь так, как тебе нужно. С рабочими и будними днями ты делаешь query и исключаешь из результата не нужные дни недели.

 

нахуй ему это сдалось, ему надо текст, где ты его брать будешь?

 

дальше тебе надо будет поделить рабочие и будние, с таблицей ты просто хуяришь доп. колонку и спокойно делаешь выборку

 

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

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

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

зачем мне делать выборку из бд если я могу сделать instancesList.filter(i => isPizda(i.fieldN))

PS: а если это еще и HList то я в компайл тайме буду точно знать типы каждого элемента получившейся выборки (в смысле если до этого инстансы были описаны своими подтипами)

"дальше тебе надо будет поделить рабочие и будние, с таблицей ты просто хуяришь доп. колонку и спокойно делаешь выборку"

зачем для этого аж целую доп колонку фигачить, думать о схеме, миграции, мапинге в ОРМ, если я это могу просто филдом класса сделать...?

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

"база главное, код вторичен"

не уверен что правильно тебя понимаю

бд это просто хранилище данных. это просто персистентный стейт твоего приложения

не совсем понял в чем тут может быть разница в "главности"

ебать тут у вас душно

енумы хранят в БД  monkamega

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

 

 

нахуй ему это сдалось, ему надо текст, где ты его брать будешь?

 

дальше тебе надо будет поделить рабочие и будние, с таблицей ты просто хуяришь доп. колонку и спокойно делаешь выборку

 

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

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

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

зачем мне делать выборку из бд если я могу сделать instancesList.filter(i => isPizda(i.fieldN))

PS: а если это еще и HList то я в компайл тайме буду точно знать типы каждого элемента получившейся выборки (в смысле если до этого инстансы были описаны своими подтипами)

 

"дальше тебе надо будет поделить рабочие и будние, с таблицей ты просто хуяришь доп. колонку и спокойно делаешь выборку"

зачем для этого аж целую доп колонку фигачить, думать о схеме, миграции, мапинге в ОРМ, если я это могу просто филдом класса сделать...?

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

"база главное, код вторичен"

не уверен что правильно тебя понимаю

бд это просто хранилище данных. это просто персистентный стейт твоего приложения

не совсем понял в чем тут может быть разница в "главности"

 

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

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

но любое желание вытащить выходные дни внутри хранимки в базе рассыпятся в пыль, тк ты не знаешь что есть выходные дни в базе, а база код внезапно дернуть не может

не говоря уже от скорости работы запросов

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

сегодня вот например бизнес запретил срать по выходным, будешь в коде менять енум и версию перевыпускать?

или сделаешь колонку в этой таблице "можно срать" и будешь вытягивать список разрешенных дней по этой колонке?

но сорян, у этого енума нет таблиц

> не делаешь табличку на дни недели

> через 5 лет надо добавить флаг "можно срать"

> срешь и в рабочие и выходные дни, перелопачивая код

ух наверну контента на выходных, наконецто бекенд срач, а не этот ваш ЖС

нужна голосовалка

 

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

 

 

А потом понадобиться дать возможность какому-то дибилу, выставлять в админке какие дни выходные, а какие рабочие и все равно придется переносить в базу.

 

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

все остальлное попрежнему в коде

и все ок. тк статика в коде и типизируется а динамика в бд и изменяется

 

 

 

нахуй ему это сдалось, ему надо текст, где ты его брать будешь?

 

дальше тебе надо будет поделить рабочие и будние, с таблицей ты просто хуяришь доп. колонку и спокойно делаешь выборку

 

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

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

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

зачем мне делать выборку из бд если я могу сделать instancesList.filter(i => isPizda(i.fieldN))

PS: а если это еще и HList то я в компайл тайме буду точно знать типы каждого элемента получившейся выборки (в смысле если до этого инстансы были описаны своими подтипами)

 

"дальше тебе надо будет поделить рабочие и будние, с таблицей ты просто хуяришь доп. колонку и спокойно делаешь выборку"

зачем для этого аж целую доп колонку фигачить, думать о схеме, миграции, мапинге в ОРМ, если я это могу просто филдом класса сделать...?

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

"база главное, код вторичен"

не уверен что правильно тебя понимаю

бд это просто хранилище данных. это просто персистентный стейт твоего приложения

не совсем понял в чем тут может быть разница в "главности"

 

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

 

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

но любое желание вытащить выходные дни внутри хранимки в базе рассыпятся в пыль, тк ты не знаешь что есть выходные дни в базе, а база код внезапно дернуть не может

не говоря уже от скорости работы запросов

 

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

сегодня вот например бизнес запретил срать по выходным, будешь в коде менять енум и версию перевыпускать?

или сделаешь колонку в этой таблице "можно срать" и будешь вытягивать список разрешенных дней по этой колонке?

но сорян, у этого енума нет таблиц

 

если у тебя хранимки которым нужна статика и вообще логика в бд - мое решение не подходит

но я не вижу причин чтобы в приложении (микросервисного типа) была логика в бд. более того там вместо рбд может быть и кафка и монга и кассандра и никаких хранимок там нет. 

да буду перевыпускать версию, если это статика то так и должно быть. если начальство каждый день хочет менять этот параметр - это не статика

разговоры "а если завтра статика станет динамикой" это на уровне "а что если мне когданибудь в будущем понадобится абстрактная фабрика абстрактной фабрики которая будет производить мне билдер синглтонов"

если такие требования веряотны и известны в ближайшем будущем - делай сразу то что пригодится, иначе не думай на 100 лет вперед потому что скорее всего ты напишешь то что никогда не будет использоваться. ну я думаю принцип бритвы окама вы и так знаете

> не делаешь табличку на дни недели

> через 5 лет надо добавить флаг "можно срать"

> срешь и в рабочие и выходные дни, перелопачивая код

в случае с бд - ты все эти 5 лет поддерживал бы более сложную семантику динамических объектов в бд что было бы гораздо дороже

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

архитектора на вас нету блеать  takpadazhi

еще от помидора:

Кто может помочь?
Вот смотрите, у меня есть xsd схемка, по которой я генерирую жаба классы
Если я просто беру и из консоли вызываю xjc myXsdSchema.xsd - то для поля isDeleted типа Boolean (не boolean) генерируется геттер isIsDeleted, но мне кроме геттеров и сеттеров нужно еще equals и hashcode

У меня есть таск в gradle, где я генерирую код классов по xsd схеме, все отлично генерит, геттеры, сеттеры, equals и хешкод, все классно НО
Вот конкретно геттер для isDeleted типа Boolean - генерируется как getIsDeleted (что правильно по спецификации javabeans)

А мне нужно сделать, чтобы он генерился isIsDeleted, потому что этот метод вызывает 50+ классов, которые написали в 2016-17 годах

Есть какие то вариации это проделать? Я погуглил, там челы советуют на жабу 6 перейти, потому что баг с генерацией xjc для поля типа Boolean был именно в ней, но так я не могу сделать

Сделать простой тип boolean в xsd схемке я тоже не могу