Ну это от вашего кейса зависит - если вам просто данные сохранить, не смотря в их структуру. То конечно не нужно к ним привязываться - просто как byte array сохраняете и всё. Но если нужно как то следить чтобы они не повторялись при обновлении, то надо смотреть как они там устроены. И если их структура поменяется, то да, у вас тоже нужно поменять схему и т.п.
За 20 лет в индустрии скажу что это зависит от предметной области. Но практически везде где я работал - хранились исторические данные
На текущем месте работы почти каждый месяц приходят запросы вида - а почему тут такое значение? кто поменял? а раньше же по другому было?
Вот последний раз это было несколько недель назад - раньше работало, а потом перестало и начали смотреть почему - а там в таблице запись поменяли, в которой конфигурация хранилась. И так как у нас есть историческая таблица - увидели кто и когда это сделал.
Ну т.е. всё равно приходим к тому что нужно хранить created, updated? И они не нужны примерно в 99%, но вот когда нужны - вот тут прям без них ни как. Это как логи - зачем в них смотреть когда всё работает? Но если что-то не так - они как раз кстати.
Есть llm, есть спорные моменты, но у нас же не научное сообщество, а инженерное и тут как известно нет серебряной пули - для какого-то приложения всё это будет работать, а для другого - нет. Так что хорошо что обсуждаем. И автор в комментах дискуссию ведёт, а не просто запостил. :-)
С rur rub пример не валиден - это же валюта другая стала.
Вообще я бы общее правило сделал - если ваше приложение данными не владеет, а просто сохраняет как есть, то тут суррогатнай ключ не нужен. (С другой стороны не всегда ясно какой тут натуральный ключ использовать, но в моей практике обычно понятно было) И курсы валют как раз хороший пример - всё что вам дали и вы записали как есть.
Но если ваше приложение создаёт данные - то оно и ключ может записать.
Вот когда вы точно уверены что это это внешне значение можно использовать как первичный ключ? Сегодня мы думаем что у нас у пользователя email - уникальный, а завтра он поменяется, или вообще будет две копии пользователя с одним email но второй будет помечен как deleted.
И когда ключи стандартизированны - типа всегда число. То можно в коде писать generic квери для обработки кучи разных таблиц одинаково.
На счёт перфоманса не понял - если там нет индексов, то в чём проблема?
Вообще ни разу не спорное. И я бы ещё добавил что лучше хранить историю изменений таблицы, для доступа к последней версии записи ввести что-то вроде is_last.
Потому что когда на проде что-то пройдёт не так и к тебе придут с вопросом, а почему тут такие значения, то гораздо удобнее ответ получить из селекта. Где будет по шагам расписано что именно кто и когда менял, чем ходить по логам и искать что там вообще было.
Логи в любом случае нужны, но из базы это всё удобнее получить и более наглядно.
И так как мы в будущее плохо смотрим, то я выбрал простую стратегию - всегда пишем, а если как то это будет негативно влиять (ни разу с этим не сталкивался, но всё же) то явно конкретно в этом месте не используем.
Но вообще всё зависит от бизнеса. В банках важно, кто когда что-то поменял (с них потом спросят), поэтому тут лучше всё писать. Где нибудь в pet project - наверное нет.
Согласен. Вот это сейчас происходит на рынке 3d принтеров:
Этому рынку уже несколько десятков лет. Из которых лет 10 уже можно было самому купить принтер за вполне демократичную цену. Но всё это было сложно и требовало прям знаний и погружения в тему. И не смотря на это было куча производителей. Но несколько лет назад пришли бывшие сотрудники DJI и по сути стали стандартом со своими BambuLab принтерами. Т.е. несмотря даже уже на развитый рынок с конкурентами - хороший продукт легко занимает большую долю. И реплики хуже, не получается скопировать.
Ну минусы llm по сравнению со stack overflow - на stack overflow есть обратная связь - комментарии и рейтинг. Т.е. можно посмотреть не только ответ, но и мнения других людей о нём.
Я сам llm использую, но я понимаю все эти минусы и знаю как оно примерно должно быть правильно. Но если знаний вообще нет - не понятно, llm говорит правду или нет.
Меня тут особенно повеселило утверждение что ИИ тесты должен писать. Ну так он конечно напишет, но всё равно нужно понимать что там происходит. А то, условно говоря, будет code coverage 100%, но asserts не будет.
И вообще не получится что бы оно как-нибудь само, а ты ему только промты пишешь. И опять всё возвращается к программисту, который должен понимать, как оно работает.
Вот статья была недавно на Хабре - делали приложение для отслеживания инсулина для кошек. Там активно ИИ использовался. Но его использовал программист, который знал что ему нужно, умел задавать правильные вопросы. И я сам в работе так ИИ использую - получается чуть ускорить разработку.
У сенсорного управления есть минусы. И мне по началу было непривычно. Но когда привык - норм. И вот сейчас у меня другие наушники (другой фирмы с костной проводимостью) и там кнопки. И мне это менее удобно, чем сенсорные жесты - при нажатии на кнопки наушники съезжают.
И вот приложение там тоже такое же бесполезное как и у Сони. Так что с приложениями возможно это общая проблема.
Я слышал что некоторые модели xm неудачные. Вроде как 4 как раз одна из них. У меня вторая уже лет 7 и ничего из перечисленного нет - ничего не ломается и не свистит. Даже аккумулятор долго держит (хотя я ими каждый день пользуюсь, а всё равно заряжаю раз в неделю).
Ну т.е. Сони тут конечно налажали, что выпустили такой продукт. Но я думаю это не прям ко всем наушникам Сони относится - вот и у автора были проблемы с 5-ой версией, а с 6-ой всё хорошо.
Большое спасибо за отзыв! У меня xm2, уже лет 7. И это одна из самых лучших покупок за всю жизнь! Супер шумоподавление - в метро, в самолёте, в офисе - всё отлично работает.
Уже амбушюры менял, но в остальном всё работает без нареканий - батарею держит, звук хороший (для меня).
Узнал про 6-у версию, которая учла прошлые ошибки и думал купить. И тут как раз ваш обзор! Так что точно куплю!
А ещё тесты нужно писать понятными, т.е. вот эту пресловутую "чистоту кода" нужно использовать в тестах. Иначе непонятный код будет покрыт непонятными тестами из которых непонятно будет что они вообще что-то проверяют.
Насколько я понял, логика тут в следующем - дети могут выбежать из за автобуса (или наоборот - бежать к нему). Да, они при этом нарушат правила, но вот так они обычно и делают - бежат не видя ничего вокруг.
Собственно взрослые тоже так себя ведут. Я хоть и имею не большой водительский стаж (около 10 лет), но тоже часто встречал ситуацию когда взрослые на красный бежали к автобусу чтобы успеть. Или выбегали впереди автобуса. В итоге я теперь всегда сильно замедляюсь перед стоящим автобусом.
Я бы тут ещё добавил про явную обработку ошибок - Java раньше по такому пути и шла - использовала по максимуму checked exception, но потом практика показала что это никому не нужно. И сейчас наоборот делают только uncheck. И кстати в java можно писать как в расте - возвращать result только с одним из значений - success с нужными объектом или error. В switch проверять. С Compile time проверкой что не забыл проверить error case.
Про Cursor не скажу, но Copilot официально используем. Но мы сертификат ставим, чтобы к github коннектиться. Возможно как раз из за ИБ - что бы они там благодаря MITM смогли смотреть что мы пишем.
Ну это от вашего кейса зависит - если вам просто данные сохранить, не смотря в их структуру. То конечно не нужно к ним привязываться - просто как byte array сохраняете и всё. Но если нужно как то следить чтобы они не повторялись при обновлении, то надо смотреть как они там устроены. И если их структура поменяется, то да, у вас тоже нужно поменять схему и т.п.
Ха ха, да, есть такое. :-)
Но вот железо обычно тонет, но не в ртути. Вот может эти железные правила обычно работают, но в некоторых условиях - нет :-D
За 20 лет в индустрии скажу что это зависит от предметной области. Но практически везде где я работал - хранились исторические данные
На текущем месте работы почти каждый месяц приходят запросы вида - а почему тут такое значение? кто поменял? а раньше же по другому было?
Вот последний раз это было несколько недель назад - раньше работало, а потом перестало и начали смотреть почему - а там в таблице запись поменяли, в которой конфигурация хранилась. И так как у нас есть историческая таблица - увидели кто и когда это сделал.
Ну т.е. всё равно приходим к тому что нужно хранить created, updated? И они не нужны примерно в 99%, но вот когда нужны - вот тут прям без них ни как. Это как логи - зачем в них смотреть когда всё работает? Но если что-то не так - они как раз кстати.
Мне вообще статья понравилась.
Есть llm, есть спорные моменты, но у нас же не научное сообщество, а инженерное и тут как известно нет серебряной пули - для какого-то приложения всё это будет работать, а для другого - нет. Так что хорошо что обсуждаем. И автор в комментах дискуссию ведёт, а не просто запостил. :-)
С rur rub пример не валиден - это же валюта другая стала.
Вообще я бы общее правило сделал - если ваше приложение данными не владеет, а просто сохраняет как есть, то тут суррогатнай ключ не нужен. (С другой стороны не всегда ясно какой тут натуральный ключ использовать, но в моей практике обычно понятно было) И курсы валют как раз хороший пример - всё что вам дали и вы записали как есть.
Но если ваше приложение создаёт данные - то оно и ключ может записать.
Сорри, но дальше комментарий можно не читать.
Вот когда вы точно уверены что это это внешне значение можно использовать как первичный ключ? Сегодня мы думаем что у нас у пользователя email - уникальный, а завтра он поменяется, или вообще будет две копии пользователя с одним email но второй будет помечен как deleted.
И когда ключи стандартизированны - типа всегда число. То можно в коде писать generic квери для обработки кучи разных таблиц одинаково.
На счёт перфоманса не понял - если там нет индексов, то в чём проблема?
Вообще ни разу не спорное. И я бы ещё добавил что лучше хранить историю изменений таблицы, для доступа к последней версии записи ввести что-то вроде is_last.
Потому что когда на проде что-то пройдёт не так и к тебе придут с вопросом, а почему тут такие значения, то гораздо удобнее ответ получить из селекта. Где будет по шагам расписано что именно кто и когда менял, чем ходить по логам и искать что там вообще было.
Логи в любом случае нужны, но из базы это всё удобнее получить и более наглядно.
И так как мы в будущее плохо смотрим, то я выбрал простую стратегию - всегда пишем, а если как то это будет негативно влиять (ни разу с этим не сталкивался, но всё же) то явно конкретно в этом месте не используем.
Но вообще всё зависит от бизнеса. В банках важно, кто когда что-то поменял (с них потом спросят), поэтому тут лучше всё писать. Где нибудь в pet project - наверное нет.
Согласен. Вот это сейчас происходит на рынке 3d принтеров:
Этому рынку уже несколько десятков лет. Из которых лет 10 уже можно было самому купить принтер за вполне демократичную цену. Но всё это было сложно и требовало прям знаний и погружения в тему. И не смотря на это было куча производителей. Но несколько лет назад пришли бывшие сотрудники DJI и по сути стали стандартом со своими BambuLab принтерами. Т.е. несмотря даже уже на развитый рынок с конкурентами - хороший продукт легко занимает большую долю. И реплики хуже, не получается скопировать.
В базах, насколько я знаю, не совсем BST, а B tree используется.
https://en.wikipedia.org/wiki/Binary_search_tree
https://en.wikipedia.org/wiki/B-tree
Ну минусы llm по сравнению со stack overflow - на stack overflow есть обратная связь - комментарии и рейтинг. Т.е. можно посмотреть не только ответ, но и мнения других людей о нём.
Я сам llm использую, но я понимаю все эти минусы и знаю как оно примерно должно быть правильно. Но если знаний вообще нет - не понятно, llm говорит правду или нет.
Меня тут особенно повеселило утверждение что ИИ тесты должен писать. Ну так он конечно напишет, но всё равно нужно понимать что там происходит. А то, условно говоря, будет code coverage 100%, но asserts не будет.
И вообще не получится что бы оно как-нибудь само, а ты ему только промты пишешь. И опять всё возвращается к программисту, который должен понимать, как оно работает.
Вот статья была недавно на Хабре - делали приложение для отслеживания инсулина для кошек. Там активно ИИ использовался. Но его использовал программист, который знал что ему нужно, умел задавать правильные вопросы. И я сам в работе так ИИ использую - получается чуть ускорить разработку.
У сенсорного управления есть минусы. И мне по началу было непривычно. Но когда привык - норм. И вот сейчас у меня другие наушники (другой фирмы с костной проводимостью) и там кнопки. И мне это менее удобно, чем сенсорные жесты - при нажатии на кнопки наушники съезжают.
И вот приложение там тоже такое же бесполезное как и у Сони. Так что с приложениями возможно это общая проблема.
Я слышал что некоторые модели xm неудачные. Вроде как 4 как раз одна из них. У меня вторая уже лет 7 и ничего из перечисленного нет - ничего не ломается и не свистит. Даже аккумулятор долго держит (хотя я ими каждый день пользуюсь, а всё равно заряжаю раз в неделю).
Ну т.е. Сони тут конечно налажали, что выпустили такой продукт. Но я думаю это не прям ко всем наушникам Сони относится - вот и у автора были проблемы с 5-ой версией, а с 6-ой всё хорошо.
Большое спасибо за отзыв! У меня xm2, уже лет 7. И это одна из самых лучших покупок за всю жизнь! Супер шумоподавление - в метро, в самолёте, в офисе - всё отлично работает.
Уже амбушюры менял, но в остальном всё работает без нареканий - батарею держит, звук хороший (для меня).
Узнал про 6-у версию, которая учла прошлые ошибки и думал купить. И тут как раз ваш обзор! Так что точно куплю!
У меня иногда он как caps lock срабатывает - начинает печатать большими буквами.
А ещё тесты нужно писать понятными, т.е. вот эту пресловутую "чистоту кода" нужно использовать в тестах. Иначе непонятный код будет покрыт непонятными тестами из которых непонятно будет что они вообще что-то проверяют.
Насколько я понял, логика тут в следующем - дети могут выбежать из за автобуса (или наоборот - бежать к нему). Да, они при этом нарушат правила, но вот так они обычно и делают - бежат не видя ничего вокруг.
Собственно взрослые тоже так себя ведут. Я хоть и имею не большой водительский стаж (около 10 лет), но тоже часто встречал ситуацию когда взрослые на красный бежали к автобусу чтобы успеть. Или выбегали впереди автобуса. В итоге я теперь всегда сильно замедляюсь перед стоящим автобусом.
Закон на вики https://en.wikipedia.org/wiki/School_bus_traffic_stop_laws
Обсуждение в редит https://www.reddit.com/r/AskAnAmerican/comments/1dxeom3/why_do_cars_have_to_stop_for_school_buses/
Я бы тут ещё добавил про явную обработку ошибок - Java раньше по такому пути и шла - использовала по максимуму checked exception, но потом практика показала что это никому не нужно. И сейчас наоборот делают только uncheck. И кстати в java можно писать как в расте - возвращать result только с одним из значений - success с нужными объектом или error. В switch проверять. С Compile time проверкой что не забыл проверить error case.
Про Cursor не скажу, но Copilot официально используем. Но мы сертификат ставим, чтобы к github коннектиться. Возможно как раз из за ИБ - что бы они там благодаря MITM смогли смотреть что мы пишем.