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

Drakonian написал 50 минут назад:

нужны железные аргументы в идеале в виде текста в инете

Нет такого. Зависит от задачи и практики использования в конкретном случае.

Вообще, ПК более очевидный и универсальный вариант.

У композитного вообще особых плюсов не вижу, если честно. Разве что тот факт, что композита может хватить для использования в некоторых кейсах (тип не нужен доп индекс).

Напиши короч аргументы за композит, разъебем. А то хуй пойми о чем речь. 0 весомых причин его использовать в описанном кейсе.

Ну я как раз таки юзаю вторичный ключ...

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

Аргумент за композитный первичный:
Эээ... ну так принятно? Ммм пук-пук производительность при гете рекорда?

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

Ок, давай попробуем аргументировать очевидный:

1) Нужна таблица line. Будем ли в неё добавлять поле идентификатора? Очевидно, да (можно раскрыть очевидность).

2) Будем ли вешать форей ки на созданное поле? Очевидно, да (аналогично, можно раскрыть). В некоторых случаях нет - тоже можно аргументировать.

3) Окей, есть ПК с ФК. Хотим ли мы в ПК запихнуть еще поле? Нахуя? Что это даст? Увеличит время вставки / апдейта иииии всё.

Основные типы использования быстрей не станут (тип header join lines on header_id = ) - энивей индекс нужен будет (разве что инвертнуть композит ПК).

В итоге хотим сделать хуйню непонятно зачем.

Единственный кейз - ПК вида "Header Id, Id" (в такой посл-ти), чтобы не создавать индекс.

А потом добавится таблица line_attributes которая будет активно читаться и всё равно нужен будет индекс. 

Drakonian написал 15 минут назад:

Можно просто ебануть филду проперти AutoIncrement и оно при каждом инсерте автоматически инкрементится, изи и просто, синк эбаут ит

У тебя бтв, видимо конкретная СУБД. Неплохо бы указывать. 

Drakonian написал 1 час назад:

Пацаны, скиньте красивую статью Foreighn Key vs. Composite Primary Key, почему мы должны юзать именно Composite Primary Key с точки зрения SQL.

А то тут спор большой, в разрезе Business Central, но суть в чем, есть две таблицы

Header: Id

Line: Id, Header Id

и типа вопрос, почему лучше делать для Line таблицы первичный ключ как Id, Header Id

почему не заюзать Id как PK  с AutoIncrement, и не сделать Header Id как Foreighn Key?

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

я вот сижу и думаю - то ли я дурак то ли лыжи не едут.

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

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

пк чтобы идентифицировать рекорд. в случае составного - чтобы идентифицировать рекорд на основе 2х полей а не одного

если у тебя рекорд идентифицируется как ид+хидер ид (тоесть возможно чтобы было 2 одинаковых ид но с разными хидерами)

обычно такое используется для таблиц связей многие ко многим. допустим у тебя есть таблица header(id, somefields...) и line(id, somefields...) и между ними связь m2m и для этого ты создаешь таблицу headerToLine(headerId, lineId) где нужен композитный ключ, тк запись идентифицируется двумя полями и по смыслу и с точки зрения ограничений. и кстати в этом всем надо будет еще и ФК навешать на headerId и lineId чтобы они не ссылались на отсутствующие значения

вроде это настолько очевидно, что мне кажется я все таки где-то дурак

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

PS: автоинкремент не юзали на проекте. когда я пришел так было, почему так сделал хз. могу предположить, что потому что порой нужно создать и сохранить дерево сущностей, и бегать сохранять одно, получать присвоенный id, а потом в дерева ниже по иерархии его записывать в качестве ссылки, а потом у этих сущностей в свою очередь сохранять, получать ид и дальше по иерархии его записывать - кажется слишком сложно. проще нагенерить хешей/UUIDов и инсертить всю пачку разом, также для особо волатильных таблиц автоинкремент под большой нагрузкой будет тормазить. хотя эту хуйню в 99.9% случаев обычного энтерпрайза можно не учитывать. другой фактор что у нас был шаблонизатор хтмл на языке бекенда и удобно было генерить UUID прямо на фронтенде а потом бек просто пробрасывает сохранение в бд уже с ид и так проще поддерживать констистентность на фронте, бекенде и базе

Лул.

Ну, судя по разговору об инкрементах, там всё-таки не м2м.

one header to many lines

СУБД MySql, как понимаю? Или куда еще независимые секвенции не подвезли?

Drakonian написал 2 часа назад:

Пацаны, скиньте красивую статью Foreighn Key vs. Composite Primary Key, почему мы должны юзать именно Composite Primary Key с точки зрения SQL.

А то тут спор большой, в разрезе Business Central, но суть в чем, есть две таблицы

Header: Id

Line: Id, Header Id

и типа вопрос, почему лучше делать для Line таблицы первичный ключ как Id, Header Id

почему не заюзать Id как PK  с AutoIncrement, и не сделать Header Id как Foreighn Key?

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

Я первый раз слышу о необходимости делать первичный ключ композитным.

Первичный ключ, это минимальный уникальный набор полей, по которому будет индефицироваться запись. В твоем случае это очевидно ID. Причем тут вообще Header?

ArzanisAncient написал 4 минуты назад:

СУБД MySql, как понимаю? Или куда еще независимые секвенции не подвезли?

СУБД - Microsoft SQL Server
 

GoldRobot написал Только что:

Drakonian написал 2 часа назад:

Пацаны, скиньте красивую статью Foreighn Key vs. Composite Primary Key, почему мы должны юзать именно Composite Primary Key с точки зрения SQL.

А то тут спор большой, в разрезе Business Central, но суть в чем, есть две таблицы

Header: Id

Line: Id, Header Id

и типа вопрос, почему лучше делать для Line таблицы первичный ключ как Id, Header Id

почему не заюзать Id как PK  с AutoIncrement, и не сделать Header Id как Foreighn Key?

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

Я первый раз слышу о необходимости делать первичный ключ композитным.

Первичный ключ, это минимальный уникальный набор полей, по которому будет индефицироваться запись. В твоем случае это очевидно ID. Причем тут вообще Header?

Почему то вся моя ERP база "из коробки" кишит такими примерами, я даж хз почему

Тада первое: можешь секвенции юзать и отвязаться от ключей вообще.

Второе - пусть дауны которые предлагают хуйню аргументируют.

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

С одноколоночным ПК будет работать, значит композит избыточен. Доказывай нахуя.

ArzanisAncient написал 6 минут назад:

Тада первое: можешь секвенции юзать и отвязаться от ключей вообще.

Второе - пусть дауны которые предлагают хуйню аргументируют. 

Та то клиент которому 60 лет, он закодил свою самописную ERP и я её перевожу в нормальный продукт от Microsoft, щас то он компанию держит с десятками клиентов в сфере букинга, но кодерское прошлое ему не дает спокойно спать и он вечно лезит в дебри со своими советами(спорами)

вот он мне как раз таки не смог привести аргументов почему надо делать через композитный ключ )))

но говорит лучше делать так 

Drakonian написал 3 минуты назад:

ArzanisAncient написал 9 минут назад:

Тада первое: можешь секвенции юзать и отвязаться от ключей вообще.

Второе - пусть дауны которые предлагают хуйню аргументируют. 

Та то клиент которому 60 лет, он закодил свою самописную ERP и я её перевожу в нормальный продукт от Microsoft, щас то он компанию держит с десятками клиентов в сфере букинга, но кодерское прошлое ему не дает спокойно спать и он вечно лезит в дебри со своими советами

вот он мне как раз таки не смог привести аргументов почему надо делать через композитный ключ )))

А, клиент еще и с бэкграундом.

Ебани цифрами.

Вот 2 варика с синтетическими данными, вот скорость вставки, апдейта, вот самый частый кейс использования. Ваш варик везде проседает (или ничего не даёт, в лучшем случае).

интерполяцию и лямбда-выражения в шарпе в ласт версиях же ввели? а то курс прохожу смотрю как другие хуярят а они интерполлируют там хотя я пока по обучалке не слова об этом не слышал

курс старый типа

вроде загуглил и вправду в ластовых

а то чет начало только учу и уже охуел

еще вопрос когда переменную создаешь что лучше писать вар или тип переменной сразу?

а то в офишиал архивах майкрософт пишут вар в коде часто и челика смотрел он говорит лучше где можно писать вар

а другой чел наоборот говорит что это считается хуевым кодом

кто прав?

@Just.Doit и еще вопрос у меня англ ниже среднего мб лучше его подучить именно чтобы документации всякие читабельны стали а потом язык? мне кажется легче будет намного

или похуй можно и без хорошего англ на джуна устроиться?

Drakonian написал 35 минут назад:

но говорит лучше делать так 

ему просто так привычнее

если ему 60 лет то как бы понятно что перестраивтаься уже сложно

типа вам нормально или как вы хотите?

если все таки как он - то хули спорить, делай что сказали

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

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

потому что ты можешь иметь несколько Line с одинаковым id, но с разными headId, что как понимаю не корректно

Drakonian написал 1 час назад:

Та то клиент которому 60 лет

Drakonian написал 1 час назад:

он вечно лезит в дебри со своими советами

Ты держись там. 

обнова

format on save перестаёт работать

обнова

начинает работать

обнова

перестаёт работать

вскод заебал

Just.Doit написал 45 минут назад:

Drakonian написал 1 час назад:

но говорит лучше делать так 

ему просто так привычнее

если ему 60 лет то как бы понятно что перестраивтаься уже сложно

типа вам нормально или как вы хотите?

если все таки как он - то хули спорить, делай что сказали

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

 

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

потому что ты можешь иметь несколько Line с одинаковым id, но с разными headId, что как понимаю не корректно

 

 

Я этот проект уже полгода в соло клепаю

устал немного от этих несущественных правок

я уже три месяца прайсы ему считаю с бесконечными изменениями и убер сложностью

Plants vs Zombies написал 1 час назад:

кто прав?

никто

зависит от контекста

нужны конкретные примеры

Plants vs Zombies написал 1 час назад:

или похуй можно и без хорошего англ на джуна устроиться?

устроится то можно

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

идеально - изучай программирование потому что это интересно и полезно

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

английский крайне важен, тк дохуя годных видосов/курсов/книжек которые только на англ

Rooster said 1 hour ago:

обнова

format on save перестаёт работать

обнова

начинает работать

обнова

перестаёт работать

 

вскод заебал

Ты как вскод, ты меня тоже заебал

Plants vs Zombies написал 3 часа назад:

интерполяцию и лямбда-выражения в шарпе в ласт версиях же ввели? а то курс прохожу смотрю как другие хуярят а они интерполлируют там хотя я пока по обучалке не слова об этом не слышал

курс старый типа

вроде загуглил и вправду в ластовых

а то чет начало только учу и уже охуел

еще вопрос когда переменную создаешь что лучше писать вар или тип переменной сразу?

а то в офишиал архивах майкрософт пишут вар в коде часто и челика смотрел он говорит лучше где можно писать вар

а другой чел наоборот говорит что это считается хуевым кодом

кто прав?

@Just.Doit и еще вопрос у меня англ ниже среднего мб лучше его подучить именно чтобы документации всякие читабельны стали а потом язык? мне кажется легче будет намного

или похуй можно и без хорошего англ на джуна устроиться?

 

Хуево гуглишь братишка, интерполяция строк - это c# 6, 2015 год , лямда-выражения это вообще c# 3, вторая половина нулевых.
по вару все зависит от кодстайла, принятого на проекте, если там на архитекторе бывший джава некромант, то скорее всего вар будет запрещен, но нормальные пацаны всегда var пишут.