- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
если файлы конвертировать в бд не как есть, а нормализируя базу, то объем может получиться меньше.
Позволю не согласится. Если сравнивать объем ненормализованной БД и нормализованной - да. Если же сравнивать объем исходных данных и объем тех же данных, помещенных в БД - нет.
StarDust, но ведь исходные данные в файлах тоже могут содержать какие-то денормализованные поля-связи , а значит в процессе нормализации эти поля уменьшатся.
если файлы конвертировать в бд не как есть, а нормализируя базу, то объем может получиться меньше.
В принципе наверное можно такую базу придумать. На практике индексы занимают объем больший чем собственно данные. Не забывайте также о введении новых сущностей как суррогатные первичные ключи или появление в физической модели новых таблиц напр для описания связи много-ко-многим. Не забываем о лог-файлах также
Ну и конечно никто не проводит полную нормализацию, иначе сильные тормоза
iopiop добавил 18.12.2011 в 09:34
Идейка, скажем так, на уровне студента первого курса, без обид.
ну что вы так.. TC как раз подошел к идее держать метаданные отдельно, вон уже и структурка выделяется потихоньку
Для поиска по метаданным строим индекс. Вот по индексу уже и будем бродить.
Это уже будет второй этап, когда ТС поймет что линейный поиск - это глупо
А дальше, глядишь, и до БД дойдет ☝
это как, БД их сжимает, что ли? ;-)
Когда-то давно (когда я также как и ТС боялся этого страшного слова - "база данных") именно так мне объясняли "старшие товарищи". Если зип сжимает текстовый файл в десятки раз - почему аналогичный принцип не может быть использован в БД? В том смысле, что одинаковые последовательности (данные) заменяются на индексы.. Удаление избыточности.. (я утрированно, но надеюсь, поняли).
Ну как-то так..
А далее все что нужно - сделать скрипт типа install.(php, aspx и т.п.) который всю работу по инсталляции и сделает.
..хотя бы развернуть из дампа - делов-то :)
Если зип сжимает текстовый файл в десятки раз - почему аналогичный принцип не может быть использован в БД? В том смысле, что одинаковые последовательности (данные) заменяются на индексы.. Удаление избыточности..
Произвольный характер доступа не позволяет использовать такую технику везде.
Так что в mysql это используется только для текстовых индексов и только в myisam.
Кроме того, есть утилита myisampack, которая позволяет сжать и записи таблицы . Правда таблица становится только для чтения.
Другие субд тоже могут использовать эту технику.
Уменьшение объема вследствие нормализации куда более реально.