АН
А разве польза от какой-то конкретно зависимости противоречит утверждению, что количество зависимостей не стоит бездумно наращивать всякими мутными пакетами?
Size: a a a
2020 July 20
АБ
Спорный вопрос, но вполне возможно, что ваша "полезная зависимость" уже подкачала вам и мутные и не мутные зависимости тоже и вот в чем в чем, а в этом пользы точно нет. И я однозначно уверен только в том, что время на изучение инструмента не должно быть и десятой частью от того времени, что понадобится на ее написание.
Д
тут еще надо незабывать о поддержке
если писать свои библиотки, то поддерживать их придется только самому
если писать свои библиотки, то поддерживать их придется только самому
АБ
Да, но и гарантий, что выбранная библиотека будет поддерживаться и, что не мало важно, не перестанет полностью удовлетворять ваши потребности тоже нет)
АН
Ну есть например такие библиотеки, которые используются в каждом втором проекте, один раз их изучешь - и наступит счастье. И да, нормальные библиотеки обычно не тащат ненужных зависимостей, а если тащат - это вызывает уже некоторые сомнения в нормальности библиотек.
Что же касается поддержки - популярную библиотеку не забросят, накрайняк - форкнут под другим именем.
Что же касается поддержки - популярную библиотеку не забросят, накрайняк - форкнут под другим именем.
АБ
Опять же стоит разграничить о чем идет речь, о серьёзной продуктовой разработке с определенными перспективами или же проходняк в стиле API с аниме картинками) Сомневаюсь, что кто-то из вас полетел бы на ракете, которая написана и поддерживается "noname" с гитхаба или бы доверили свои деньги ORM, в которой завтра пьяный юзер закомитит ошибку)
Д
раз уж так хорошо зашла тема касающаяся баз данных,
при каких обстоятельствах может быть разумно использовать NoSQL решения вместо SQL?
при каких обстоятельствах может быть разумно использовать NoSQL решения вместо SQL?
АБ
Есть четкие структуры и жёсткая связь межлу ними - sql, есть набор данных, которые постоянно меняются и их просто надо куда то положить - nosql
АБ
Это очень кратко и обобщенно)
АН
NoSQL вполне можно использовать не вместо, а вместе с SQL, например, для кешей. А данные, постоянно меняющие структуру, вообще не есть хорошо, а NoSQL создает подобный соблазн
A
раз уж так хорошо зашла тема касающаяся баз данных,
при каких обстоятельствах может быть разумно использовать NoSQL решения вместо SQL?
при каких обстоятельствах может быть разумно использовать NoSQL решения вместо SQL?
Если данных много, то появляется еще один фактор, который обычно не упомянают - цена вопроса. Порой бывает так что при равной производительности nosql базы просто дешевле.
Y
Документы, неструктурированные данные. Шардинг
A
С другой же стороны, если данных мало, как и денег на БД, то гораздо проще найти у различных провайдеров managed постгрес и использовать его, храня неструктурированные данные в жсон полях
Т
С другой же стороны, если данных мало, как и денег на БД, то гораздо проще найти у различных провайдеров managed постгрес и использовать его, храня неструктурированные данные в жсон полях
Мсье знает толк😊
Y
С другой же стороны, если данных мало, как и денег на БД, то гораздо проще найти у различных провайдеров managed постгрес и использовать его, храня неструктурированные данные в жсон полях
И строить сложные запросы и агрегацию поверх.
Д
принял, благодарю
АП
А ещё рсубд как правило медленнее при вставке и редактировании данных
Д
а при каких случаях скорость вставки и редактирования может быть критичной?
АП
а при каких случаях скорость вставки и редактирования может быть критичной?
При большом их количестве в единицу времени 🤷♂
АБ
Realtime приложения, как вариант, с большим количеством пользователей