Очень странно. В моей Ubuntu столько хлама в плане софта, но не вылезает за 20 гигов (~19 на данный момент)
/home тоже на ssd, кстати. Отдельным небольшим разделом. Так как там раскиданы конфиги всего этого зоопарка, запуск системы происходит моментально, 3 секунды примерно.
Всё, что является тяжелым (Steam-библиотека, к примеру) отлично себя чувствует на ёмком HDD. Ну и всякий хлам по типу торрентов.
Кстати, я стараюсь не допускать идентичности NULL и 0
Да все стараются, как вы сказали, «с опытом». NULL разрешается только там, где он логически необходим, а на практике это не так уж и часто.
Но структуры достаются по наследству, либо сам не очень удачно спроектировал и т.д., когда на рефакторинг ресурсов нет, имеем что имеем…
Естественно, если это код будет храниться. Если это разовый наколеночный запрос иногда костыли выручают. Ну и пример ниже придётся довольно сложно раскладывать
Вот, кстати, прямо сейчас наткнулся на проблему с GREATEST и NULL. По задаче надо выбрать все положительные числа, вместо отрицательного — ноль. Но с сохранением NULL, а она не сохраняет его.
На скорую руку можно обойтись таким костылём:
Пояснение:
Тип поля — numeric, сначала преобразуется в integer, затем в boolean затем опять в integer. В итоге при любом значении поля, отличном от нуля, получим единицу на выходе. Или NULL, если field IS NULL.
И с тем же успехом можно по углам предусмотреть резиновые накладки-бампера, которые в большинстве случаев падения предохранят экран, но будут вписаны в дизайн девайса.
А сейчас как? Купили нежный обмылок, красивый и приятный в руках, и натянули на него китайский г*дон, который портит и внешний вид и ощущения (не те, ага). И так с ним до последнего.
Ну, думаю, COALESCE знаком всем, кто плотно работает с PostgreSQL. Конструкции вида WHERE COALESCE(field, 0) = 0 и подобные встречаются повсеместно, если тип поля допускает NULL. А на разовых запросах позволяет не вспоминать, что там за поле что оно допускает.
Может и не 6, а 10… что-то засомневался, доберусь до БД проверю.
Сама функция работает мгновенно, т.е. select field и select similarity(field, 'static text') работает одинаково практически.
«в лоб» будет медленно, т.е. надо для каждой строки из первой таблицы найти по всем записям similarity второй таблицы, сортирнуть по ней, и взять с наивысшим соответствием. Вот именно так я вчера и проверял, у меня уходило секунд ~6 на запись (limit 10 всего запроса работал минуту).
Правда у меня объём был 230к, зато реальных данных. И связка очень красиво так получилась! Адреса разной структуры — в одном опущена область, в другом индекс, первый структурированный с разделителем, второй ручной ввод.
Естественно некий процент ошибок будет, но это лучше, чем всё лопатить руками.
А разве не две тильды соответствует LIKE? То есть LIKE '%text%' = ~~'%text%'
С одной тильдой во-первых не будет работать, во-вторых в исходниках представлений LIKE автоматически заменяется на две тильды, ILIKE со звёздочкой соответственно.
Капитаны кораблей осведомлены о районах, где нельзя сбрасывать якорь из-за возможности повредить подводный кабель
Жестоко. Туда не ходи, сюда не ходи, а тут ещё и якорь не сбрасывай.
Вроде как глубина, где якорь может быть сброшен, вполне ограничена, не разумнее ли закапывать там кабели? Ясно, что дороже, но ремонт потом ещё дороже выйдет.
Вообще английского достаточно. Если турист из бананоляндии не сможет два слова на английском выдавить в экстренной ситуации (которые надо обязательно выучить при намерении отправиться в другую страну), то, наверное, сам себе буратино.
/home тоже на ssd, кстати. Отдельным небольшим разделом. Так как там раскиданы конфиги всего этого зоопарка, запуск системы происходит моментально, 3 секунды примерно.
Всё, что является тяжелым (Steam-библиотека, к примеру) отлично себя чувствует на ёмком HDD. Ну и всякий хлам по типу торрентов.
Да все стараются, как вы сказали, «с опытом». NULL разрешается только там, где он логически необходим, а на практике это не так уж и часто.
Но структуры достаются по наследству, либо сам не очень удачно спроектировал и т.д., когда на рефакторинг ресурсов нет, имеем что имеем…
Собственно, вопрос в том, нет ли что-то похожего на greatest/least с учетом null? Нагуглить сходу не удалось.
На скорую руку можно обойтись таким костылём:
Пояснение:
Тип поля — numeric, сначала преобразуется в integer, затем в boolean затем опять в integer. В итоге при любом значении поля, отличном от нуля, получим единицу на выходе. Или NULL, если field IS NULL.
А сейчас как? Купили нежный обмылок, красивый и приятный в руках, и натянули на него китайский г*дон, который портит и внешний вид и ощущения (не те, ага). И так с ним до последнего.
WHERE COALESCE(field, 0) = 0и подобные встречаются повсеместно, если тип поля допускает NULL. А на разовых запросах позволяет не вспоминать, что там за поле что оно допускает.Сама функция работает мгновенно, т.е.
select fieldиselect similarity(field, 'static text')работает одинаково практически.И в Сибири, и в Сахаре, ага.
Может это один и тот же Лиф, но очень шустрый? :)
Правда у меня объём был 230к, зато реальных данных. И связка очень красиво так получилась! Адреса разной структуры — в одном опущена область, в другом индекс, первый структурированный с разделителем, второй ручной ввод.
Естественно некий процент ошибок будет, но это лучше, чем всё лопатить руками.
С одной тильдой во-первых не будет работать, во-вторых в исходниках представлений LIKE автоматически заменяется на две тильды, ILIKE со звёздочкой соответственно.
Жестоко. Туда не ходи, сюда не ходи, а тут ещё и якорь не сбрасывай.
Вроде как глубина, где якорь может быть сброшен, вполне ограничена, не разумнее ли закапывать там кабели? Ясно, что дороже, но ремонт потом ещё дороже выйдет.