Предложенное решение как-то самопальщиной отдает. Если надо быстренько домой слазить забрать файлик ftp + терминалка гораздо удобнее. Хотя бы потому что настраивать почти ничего не надо.
В промышленных маштабах, когда надо ходить в рабочую сеть из дома работать гораздо лучше использовать железные решения вроде Cisco VPN.
Они гораздо надежнее. И настроек на клиенте минимум. Поставили клиента, вставили ключик и все работает.
Если для конторы плата за интернет по тарифу для юрлиц это серьезный расход и она готова идти на ухищрения чтобы платить поменьше, то нафиг надо бежать из такого места. У них серьезные финансовые проблемы.
> «То будет гораздо эффективнее создать составной индекс (id, code) и автоматически > созданный (id) будет только мешать.» не будет, статистика наше все :)
Будет мешать при вставках в таблицу. Да и нефига лишние индексы держать в схеме, отвлекают.
Пожалуйста прочитайте оригинал. И эту статью посмотрите повнимательнее.
«Сильно зависит» это миф!
Если посмотреть код и результаты выполнения, то это понятно.
COUNT(*) именно поэтому медленнее и отработал. Согласен там наложилось то что таблица из одного поля. Но это не так принципиально, основную идею видно. Индекс бывает медленнее, а в каких именно случаях разбирать на целую статью хватит.
Ага, 10 хорошо знает где какой метод доступа использовать. Пришлось хинты писать чтобы Index Scan получить.
1. А как иначе? Код чтобы легко повторить у себя можно было. Просто создаем пустую схему, копируем, выполняем и изучаем почему так получилось.
2. AdBlock и никаких баннеров на хабре я не вижу
3. Кто как привык. Мне из дуала удобнее.
Документация теряется элементарно. Проект сделан, сдан. Контора сделавшая его исчезла.
На доделывание отдали другой. Шанс найти документацию стремится к 0.
Ага, надо знать что конфиг есть, и что оно в нем описано. На поиски в лучшем случае день уйдет. Скорее 2-3 дня.
Зачем плодить таки сложности буквально на пустом месте.
Кому мешают это 30 полей? Винты сейчас вообще ничего не стоит. Ограничений на количество столбцов в таблице можно считать что нет.
И что мы выигрываем от такого хранения?
Минусы понятны сразу:
— Непонятная БД
— Непонятное приложение
— Сложный код и там и там
— Необходима внешняя документация
— Тормоза в перспективе
За такое хранение расстрел на месте.
Через год вспомнить что там и как лежит будет невозможно.
Хорошо если документация будет. А если потеряется?
Если нужно 30 полей, пускай будет 30 полей.
Кому они мешают? Пускай лежат себе, с нормальными названиями, комментариями к полям. Никакой документации не нужно и так понятно откуда что брать.
Это далеко не панацея.
Если ускорять каждый запрос создавая именно под него индекс, то мы получим жуткий провал при INSERT или UPDATE по этой таблице.
Возможно стоит изменить запрос так чтобы он использовал какой-нибудь из уже существующих индексов, или создать один накрывающий индекс, который пускай не идеально, но подойдет под большинство запросов.
Вы много видели проектов написанных именно на чистом ANSI SQL?
Всегда и везде используются расширения языка, просто потому что это удобно. Сильно ускоряется процесс разработки, упрощается код, улучшается производительность.
Неизвестно даже что проще. Сделать 2 версии заточенные под конкретные СУБД или одну но совместимую со всем.
А мифическая переносимость нужна очень редко. Какому нормальному человеку потребуется зачем-то менять один сервер на другой?
Это все хорошо в теории. На практике разработка под несколько разных СУБД означает разработку разных БД.
Почти весь код переписывать приходится. Отличия незначительные только на первый взгляд.
Ради этого можно переходить на 2008.
Не нашел в обзоре ничего про версионность/блокирование данных при запросах.
Что-нибудь в алгоритмах поменялось? Или как в 2005 все?
Потом не разберешься.
Давайте еще напишем статью про 10 способов объявить и инициализировать переменную.
В промышленных маштабах, когда надо ходить в рабочую сеть из дома работать гораздо лучше использовать железные решения вроде Cisco VPN.
Они гораздо надежнее. И настроек на клиенте минимум. Поставили клиента, вставили ключик и все работает.
Будет мешать при вставках в таблицу. Да и нефига лишние индексы держать в схеме, отвлекают.
«Сильно зависит» это миф!
Если посмотреть код и результаты выполнения, то это понятно.
Ага, 10 хорошо знает где какой метод доступа использовать. Пришлось хинты писать чтобы Index Scan получить.
1. А как иначе? Код чтобы легко повторить у себя можно было. Просто создаем пустую схему, копируем, выполняем и изучаем почему так получилось.
2. AdBlock и никаких баннеров на хабре я не вижу
3. Кто как привык. Мне из дуала удобнее.
Это строка длиной 1024 символа.
Если есть индекс по полю, то что именно лежит в этом поле абсолютно не важно.
На доделывание отдали другой. Шанс найти документацию стремится к 0.
Ага, надо знать что конфиг есть, и что оно в нем описано. На поиски в лучшем случае день уйдет. Скорее 2-3 дня.
Зачем плодить таки сложности буквально на пустом месте.
Кому мешают это 30 полей? Винты сейчас вообще ничего не стоит. Ограничений на количество столбцов в таблице можно считать что нет.
И что мы выигрываем от такого хранения?
Минусы понятны сразу:
— Непонятная БД
— Непонятное приложение
— Сложный код и там и там
— Необходима внешняя документация
— Тормоза в перспективе
Через год вспомнить что там и как лежит будет невозможно.
Хорошо если документация будет. А если потеряется?
Если нужно 30 полей, пускай будет 30 полей.
Кому они мешают? Пускай лежат себе, с нормальными названиями, комментариями к полям. Никакой документации не нужно и так понятно откуда что брать.
Если ускорять каждый запрос создавая именно под него индекс, то мы получим жуткий провал при INSERT или UPDATE по этой таблице.
Возможно стоит изменить запрос так чтобы он использовал какой-нибудь из уже существующих индексов, или создать один накрывающий индекс, который пускай не идеально, но подойдет под большинство запросов.
Всегда и везде используются расширения языка, просто потому что это удобно. Сильно ускоряется процесс разработки, упрощается код, улучшается производительность.
Неизвестно даже что проще. Сделать 2 версии заточенные под конкретные СУБД или одну но совместимую со всем.
А мифическая переносимость нужна очень редко. Какому нормальному человеку потребуется зачем-то менять один сервер на другой?
Если сами знаете что это не так?
350 рублей за файл
Программирование на Python
А за 390 рублей можно купить тоже самое на бумаге
Спасибо, нам такое не нужно!
В 95% случаев будет использоваться один индекс с самой большой селективностью.
Почти весь код переписывать приходится. Отличия незначительные только на первый взгляд.