> Поэтому я и написал «в 90% случаев».
Для этого существуют соответствущие инструменты. База не должна об этом думать
> Каким образом с помощью агрегатных функций можно убрать дублирование строки таблицы articles в этом запросе?
group by articles.id
а все камменты обернуть в какой-нибудь array_agg, предварительно преобразовав в json, например
> Поддержку, то есть чтение и написание кода
Тогда точно не надо уметь выносить объекты в отдельную таблицу без нарушения связей. На архитектуру такое повлияет очень «не очень».
Data vault или ancor modeling применяют в проектах с часто меняющимися требованиями
— Условие джойна
Условия джойна бывают не только по FK, не только по равенству и тд. Кроме того, дата сатанисты не указывают FK в 95% проектов. В частности по той причине, что FK в аналитических базах не работают и не вырезаны от туда совсем только для документации. — Джойн для получения данных связанной сущности это вообще неоптимальная вещь.
Это решается довольно просто при помощи агрегатных функций
— Одна таблица на структуру данных.
«Оба хуже».
Смотря что здесь хочется оптимизировать. Если не хочется писать условия на is_deleted в запросах, но при этом удаленные нужно сохранять — то это совсем непонятно. Либо можно удалять данные, либо нельзя. Лучше второе :)
Если оптимизируется скорость:
— (в зависимости от базы) можно сделать, например, партиционирование. И тогда deleted будут физически лежать в физически отдельной таблице.
— сделать условные индексы для is_deleted = true и is_deleted = false.
Но лучше не делать булевых полей совсем, а вместо них делать даты, когда этот deleted произошел. Очень поможет в будущем :)
Он сделал большой вклад в индустрию, сделав prettier.
Но это — позор, как он есть.
Такие статьи встречаются регулярно, и довольно часто в корпоративных блогах. Видимо, у людей какой-то план по публикациям и получаются такие материалы. Но его никто не заставлял в свой блог писать, я полагаю…
Столько стоило разработать божественный котлин.
Т.е. нужен какой-то проклятый капиталист, который оплатит этот банкет.
А так да, свой язык как мечта, вот это вот всё…
Ваш коллега с темной стороны утверждает, что не стоит придумывать exit opportunities.
2 дня назад:
«Не догоню, так хоть согреюсь»
Хватит добавлять в презентации стартапов ранних стадий слайд со стратегиями экзита. Если мы знаем, кому мы собираемся продать стартап, который мы только что создали — мы опоздали на 5–7 лет.
Вы утверждаете обратное.
Вы точно в united investors в одну сторону воюете? :)
Чтобы импортировать в 2018.2, видимо, надо было их сначала экспортировать в 2018.1, но я об этом ничего не знал.
просто подменить папку projects помогает частично. частично — проекты видны, но подсвечены красным и подклбчится нельзя из-за экскпшена.
вопрос — могу ли я где-то скачать 2018.1, забекапмтся и импортнуть в 2018.2?
Что касается каппучинатора, искренне рекомендую отдельный девайс в виде небольшого чайника. Что-нибудь в духе GRETTI
Во много раз удобнее встроенного в кофемашину, можно теплую пену, можно холодную, не говоря уже о стабильности результата )
Для этого существуют соответствущие инструменты. База не должна об этом думать
> Каким образом с помощью агрегатных функций можно убрать дублирование строки таблицы articles в этом запросе?
group by articles.id
а все камменты обернуть в какой-нибудь array_agg, предварительно преобразовав в json, например
> Поддержку, то есть чтение и написание кода
Тогда точно не надо уметь выносить объекты в отдельную таблицу без нарушения связей. На архитектуру такое повлияет очень «не очень».
Data vault или ancor modeling применяют в проектах с часто меняющимися требованиями
Условия джойна бывают не только по FK, не только по равенству и тд. Кроме того, дата сатанисты не указывают FK в 95% проектов. В частности по той причине, что FK в аналитических базах не работают и не вырезаны от туда совсем только для документации.
— Джойн для получения данных связанной сущности это вообще неоптимальная вещь.
Это решается довольно просто при помощи агрегатных функций
— Одна таблица на структуру данных.
«Оба хуже».
Смотря что здесь хочется оптимизировать. Если не хочется писать условия на is_deleted в запросах, но при этом удаленные нужно сохранять — то это совсем непонятно. Либо можно удалять данные, либо нельзя. Лучше второе :)
Если оптимизируется скорость:
— (в зависимости от базы) можно сделать, например, партиционирование. И тогда deleted будут физически лежать в физически отдельной таблице.
— сделать условные индексы для is_deleted = true и is_deleted = false.
Но лучше не делать булевых полей совсем, а вместо них делать даты, когда этот deleted произошел. Очень поможет в будущем :)
А есть еще такая архитектура как anchor modeling…
Можно было бы это простить, если бы это на review нашлось :)
В постгре это точно не так и зависит от огромного количества факторов. В частности от интенсивности чтения, изменения и собственно самой записи.
Миллион вставок всегда будут очень медленными. А если вставить батчем, то это утверждение может быть верным далеко не всегда.
Остальные советы тоже хороши в ограниченном количестве случаев. Например, если работаете с финансами так лучше не делать :)
Но это — позор, как он есть.
Такие статьи встречаются регулярно, и довольно часто в корпоративных блогах. Видимо, у людей какой-то план по публикациям и получаются такие материалы. Но его никто не заставлял в свой блог писать, я полагаю…
Этот товарищ, кроме своего пет-проекта actual еще и работает в stripe.
Но это не главное.
Он тот, кто придумал prettier.
Это позор автора.
Статья не стоила времени, затраченного на перевод.
На vc есть статья от jetbrains и в ней есть цифра $35m.
Столько стоило разработать божественный котлин.
Т.е. нужен какой-то проклятый капиталист, который оплатит этот банкет.
А так да, свой язык как мечта, вот это вот всё…
Это ж пхпшный бар. Может кончиться мордобоем :)
А разве вы не должны быть за одно, если вы партнеры? оО
Ваш коллега с темной стороны утверждает, что не стоит придумывать exit opportunities.
2 дня назад:
«Не догоню, так хоть согреюсь»
Вы утверждаете обратное.
Вы точно в united investors в одну сторону воюете? :)
но че-то это нифига не юзерфрендли. и первый раз такой квест прилетает с обновлением
не предложил :)
пользуюсь начиная с версии 2017.1 — ни единого разрыва! а тут такое :)
заменил папку, скачал драйвер, все стало ок
Чтобы импортировать в 2018.2, видимо, надо было их сначала экспортировать в 2018.1, но я об этом ничего не знал.
просто подменить папку projects помогает частично. частично — проекты видны, но подсвечены красным и подклбчится нельзя из-за экскпшена.
вопрос — могу ли я где-то скачать 2018.1, забекапмтся и импортнуть в 2018.2?
ваш платящий пользователь
GRETTI MF-11 Chrome
Во много раз удобнее встроенного в кофемашину, можно теплую пену, можно холодную, не говоря уже о стабильности результата )
За такое, не то, что тапкой…