"Не мокайте то, чем вы не владеете", на мой взгляд, странное утверждение.
А если бы сторонний фреймворк предоставлял не обобщенную функцию get(), а давал возможность создавать методы getId(), getAmount(), getPrice() напрямую (аля аннотациями как в Java Spring), то над каждым таким методом надо делать свою обертку и мокать ее?
Я бы перефразировал "Не мокайте обощенные функции, которыми не владеете" и вообще не создавайте свои обобщенные функции. :D
Дома ПК, который не апался лет так 8-9. С такими ценами он еще до 2025 года апаться не будет. А в принципе не сильно и надо. Не буду пока поддаваться на провокации )))).
С каких это пор в такой таблице разрешено вообще что-либо обновлять?
Ваш подход понятен - запрет на обновление записей, корректировки - это просто новые записи. И соглашусь, в большинстве реализаций подобных систем он будет применим, оправдан и целесообразен.
Но так ведь весь сыр-бор в этой ветке я начал с цитаты из статьи:
При этом никакого поиска по этой таблице не происходит, только вставка и обновление данных.
Акцепт на "обновление данных", а это подразумевает и поиск и однозначную идентификацию записи, а для этого необходим первичный ключ (не обязательно суррогатный, но хотя бы нативный быть должон). Его можно конечно не объявлять первичным ключом, но уникальность по нему должна обеспечиваться.
Представим, что это некий буффер продаж за день, где key - это продавец, descr - это товар, а amount - это цена, за которую он ее продал.
За один день продавец debug продал 3 колбасы, но в какой-то момент вспомнил, что вторую колбасу он продал не за 20, а за 30 у.е. и захотел это исправить. Но при такой структуре у него это уже не получится сделать.
Можно создать таблицу для хранения key-value значений, и первичный ключ тут не будет обязательным.
Так ведь ваше key в данном случае и является первичным ключом, разница лишь в том, что вы не указали это явно при создании таблицы, а держите это только у себя в голове, зная, что по заданному key вы однозначно определите нужную запись. Так что говорить, что тут нет первичного ключа от части совсем, ихмо, будет неправильно.
На самом деле, наличие первичного ключа не есть наличие соответствующего индекса. Это зачастую зависит от реализации СУБД. Т.е. теоретически, ничто не мешает нам создать первичный ключ и не использовать соответствующий индекс.
Просто, в таком случае, проверка уникальности первичного ключа и поиск по нему будет более трудозатратной для СУБД.
Представим у нас есть 3 записи с полями descr, amount, key:
1) key=debug, amount=10, descr='колбаса'
2) key=debug, amount=20, descr='колбаса'
3) key=info, amount=25, descr='масло'
Мне нужно обновить вторую запись, поменяв сумму с 20 на 30. Условия "WHERE key="debug"" будет явно недостаточно. И даже добавление условия "descr='колбаса'" тоже будет не достаточным. А если у нас есть 2 абсолютно одинаковые записи, например добавим 4-ю запись:
4) key=debug, amount=20, descr='колбаса'
А мне по прежнему нужно обновить вторую запись, при этом не затронув 4-ю. То я уже это просто не смогу сделать, т.к. нет критерия однозначного определения нужной записи.
Т.е. для обновления/удаления записей нам де факто просто необходим первичный ключ, даже если мы его явно не определяем для таблицы, а держим только у себя в голове.
При этом никакого поиска по этой таблице не происходит, только вставка и обновление данных.
Интересно, а как находить и обновлять нужную запись, если на ней нет первичного ключа?
А если ссылочная целость чего-то нам не дает сделать, что значит мы пытаемся что-то сделать не так, как это планировалось при проектировании, а это скорее всего ошибка с нашей стороны. А без нее (целостности) все так прекрасно работает и ошибок не выдает (хотя они есть, но их никто не видит, до поры до времени).
null - легко выявляется на продакшене, а при разработке можно и пропустить за цепочкой вызовов методов/свойств или просто по лени с мыслью "да, там null, никогда не будет, я в этом уверен".
А Котлин же вынудит тебя обратить на это внимание, иначе проект просто не будет компиляться.
Нативной jave бы перенять эту работу с null-типами, было бы здорово.
CHECK (created_at >= '2021-03-01'::DATE AND created_at < '2021-04-01'::DATE)
непосредственно в самой партиции, если разноску все равно приходится делать через отдельную функцию и там дублировать эти же условия? Странно как то это выглядит, как по мне.
Меньше устают глаза.
У меня от белой темы рябит в глазах и появляется слабый привкус во рту, как-будто я пожевал детскую соску. От темной темы такого не припоминаю.
Кажется мне, что вы упускаете фразу «Но на самом деле буду за 350К работать в плюс-минус таких же условиях, как и везде.»
Т.е. условия то, по большому счету, не поменяются, а плюс к ЗП не 50-100, как вы написали, а 200к.
Ну может не будет уже плейстешена и теннисного стола, так все равно их, как правило, запрещают в рабочее время (играй на обеде или после работы, а на работу я хожу не ради возможности поиграть в плойку после работы)
Обратное тоже очень даже вероятно: добавил отступ, задача ушла в тест, тестировщик протестил, время потратил, отдал заказчику. А заказчик: а зачем тут отступ?… и в баг-треккер на доработку.
"Не мокайте то, чем вы не владеете", на мой взгляд, странное утверждение.
А если бы сторонний фреймворк предоставлял не обобщенную функцию get(), а давал возможность создавать методы getId(), getAmount(), getPrice() напрямую (аля аннотациями как в Java Spring), то над каждым таким методом надо делать свою обертку и мокать ее?
Я бы перефразировал "Не мокайте обощенные функции, которыми не владеете" и вообще не создавайте свои обобщенные функции. :D
Дайте две. Готов работать в три смены.
Полагаю, инь-янь нам в помощь ))))
У родителей стоит Е5200, конечно не летает, но видосики в принципе без тормозов показывает, правда он на SDD.
А наш прайс если посмотреть, то там последовательность цен такая:
1) ~6000
2) ~6300
...
5) ~ 7100
6) ~ 10 500
7) ~ 63 500
8) ~ 65 000
...
Куда пропал сегмент 10к-60к? (Майнеры, ёп-та)
Т.е. грубо начинается с 63К, а на то, что ниже даже CS из 2000х считай уже не запустишь.
Пффф. 2320
КДома ПК, который не апался лет так 8-9. С такими ценами он еще до 2025 года апаться не будет. А в принципе не сильно и надо. Не буду пока поддаваться на провокации )))).
С каких это пор в такой таблице разрешено вообще что-либо обновлять?Ваш подход понятен - запрет на обновление записей, корректировки - это просто новые записи. И соглашусь, в большинстве реализаций подобных систем он будет применим, оправдан и целесообразен.
Но так ведь весь сыр-бор в этой ветке я начал с цитаты из статьи:
При этом никакого поиска по этой таблице не происходит, только вставка и обновление данных.Акцепт на "
обновление данных", а это подразумевает и поиск и однозначную идентификацию записи, а для этого необходим первичный ключ (не обязательно суррогатный, но хотя бы нативный быть должон). Его можно конечно не объявлять первичным ключом, но уникальность по нему должна обеспечиваться.Почему же такой пример не имеет право на жизнь?
Представим, что это некий буффер продаж за день, где key - это продавец, descr - это товар, а amount - это цена, за которую он ее продал.
За один день продавец debug продал 3 колбасы, но в какой-то момент вспомнил, что вторую колбасу он продал не за 20, а за 30 у.е. и захотел это исправить. Но при такой структуре у него это уже не получится сделать.
Можно создать таблицу для хранения key-value значений, и первичный ключ тут не будет обязательным.Так ведь ваше key в данном случае и является первичным ключом, разница лишь в том, что вы не указали это явно при создании таблицы, а держите это только у себя в голове, зная, что по заданному key вы однозначно определите нужную запись. Так что говорить, что тут нет первичного ключа от части совсем, ихмо, будет неправильно.
На самом деле, наличие первичного ключа не есть наличие соответствующего индекса. Это зачастую зависит от реализации СУБД. Т.е. теоретически, ничто не мешает нам создать первичный ключ и не использовать соответствующий индекс.
Просто, в таком случае, проверка уникальности первичного ключа и поиск по нему будет более трудозатратной для СУБД.
Представим у нас есть 3 записи с полями descr, amount, key:
1) key=debug, amount=10, descr='колбаса'
2) key=debug, amount=20, descr='колбаса'
3) key=info, amount=25, descr='масло'
Мне нужно обновить вторую запись, поменяв сумму с 20 на 30. Условия "WHERE key="debug"" будет явно недостаточно. И даже добавление условия "descr='колбаса'" тоже будет не достаточным. А если у нас есть 2 абсолютно одинаковые записи, например добавим 4-ю запись:
4) key=debug, amount=20, descr='колбаса'
А мне по прежнему нужно обновить вторую запись, при этом не затронув 4-ю. То я уже это просто не смогу сделать, т.к. нет критерия однозначного определения нужной записи.
Т.е. для обновления/удаления записей нам де факто просто необходим первичный ключ, даже если мы его явно не определяем для таблицы, а держим только у себя в голове.
При этом никакого поиска по этой таблице не происходит, только вставка и обновление данных.Интересно, а как находить и обновлять нужную запись, если на ней нет первичного ключа?
А если ссылочная целость чего-то нам не дает сделать, что значит мы пытаемся что-то сделать не так, как это планировалось при проектировании, а это скорее всего ошибка с нашей стороны. А без нее (целостности) все так прекрасно работает и ошибок не выдает (хотя они есть, но их никто не видит, до поры до времени).
А я пока так делаю:
companion object {private val log = LoggerFactory.getLogger(this::class.java)}null - легко выявляется на продакшене, а при разработке можно и пропустить за цепочкой вызовов методов/свойств или просто по лени с мыслью "да, там null, никогда не будет, я в этом уверен".
А Котлин же вынудит тебя обратить на это внимание, иначе проект просто не будет компиляться.
Нативной jave бы перенять эту работу с null-типами, было бы здорово.
И это будет одно устройство ))))
Точно.
Наличие подобного ограничения хорошо поможет оптимизатору выполнять запросы на выборку из такой партицированной таблицы.
А исключение пересечения, на мой субъективный взгляд, уже дело второстепенное.
А для чего нужно указывать чек:
CHECK (created_at >= '2021-03-01'::DATE AND created_at < '2021-04-01'::DATE)
непосредственно в самой партиции, если разноску все равно приходится делать через отдельную функцию и там дублировать эти же условия? Странно как то это выглядит, как по мне.
У меня от белой темы рябит в глазах и появляется слабый привкус во рту, как-будто я пожевал детскую соску. От темной темы такого не припоминаю.
Т.е. условия то, по большому счету, не поменяются, а плюс к ЗП не 50-100, как вы написали, а 200к.
Ну может не будет уже плейстешена и теннисного стола, так все равно их, как правило, запрещают в рабочее время (играй на обеде или после работы, а на работу я хожу не ради возможности поиграть в плойку после работы)