1 мая 2008 в 9:19
Сейчас вот пишу некий модуль. В нём требуется сделать поддержку "профилей" - то есть просто несколько возможных вариантов настроек. Что будет правильнее для этого использовать - системную таблицу variables или создавать свою собственную? Я склоняюсь ко второму...
Update:
Но, кстати, скорее всего на большинстве сайтов в этой таблице будет всего лишь одна запись... Вот и вопрос: какие минусы будут у способа с созданием собственной таблицы?
И ещё: запись нужна будет всего лишь несколько раз в сутки. Пока что...
Для чего мне всё это надо? Пишу модуль полного бэкапа с использованием только PHP - кода (насколько я понимаю, те модули, которые есть, используют утилиты коммандной строки, которые не везде доступны). Использую в нём Schema API, так что это должно получиться довольно-таки удобно...
Комментарии
если записей не много и они не сложные то зачем создавать новую таблицу?
А зачем загружать их каждый раз при обращении к старице? Я, конечно, понимаю, что всё это берётся из кеша, но всё же... Да к тому же и прямо-таки на таблицу наскребается: id + имя + путь + ещё два поля... В дальнейшем - ещё расширение... Хотя, вообще-то, по отдельности, скорее всего, они не будут, поэтому их с успехом мог бы заменить explode. В то же время пришлось бы заводить бы ещё одну переменную, отвечающую за перечесление, какие же профили были созданы... И, соответственно, в каких переменных хранятся данные... Поэтому и возник вопрос...
Я бы использовал переменные.
НФБК это конечно хорошо и здорово, но если не треба делать запросы, то и реляционная БД - никчему. В друпале и без нас хватает всяких чудо запросов.
Я бы загнал в переменные в сериализованном виде
Как в рекламе: Зачем тебе весь мир, если ты туда не звониш
Тогда своя таблица. Благо с созданием и удалением таблиц в drupal никаких проблем.
мускуль любит много маленьких таблиц,нежели одну большую
P.S. От создателей liveinternet
полный бред. Было бы интересно на источник взглянуть.
Любому SQL и MySQL не исключение удобнее работать с одной большой, с хорошими индексами таблицей, чем с кучей мелких. Это аксиома SQL.
К автору: а в чем особенность модуля backup-a? Чем плох cron? Почему нельзя проверить дату создания предыдущего файла архива?
Сдаётся мне, что у вас неправильная начальная установка.
Да всё хорошо. Только чем конкретно его делать, если консольные утилиты недоступны? При чём тут начальная установка?
полный бред-это заявление PVasili по сравнению с разработчиками liveinternet.
http://www.rit2008.ru/paper_view.html?id=1797
изучайте матчасть. аксиома жизни.
Не надо путать полноценный SQL-сервер и MySQL. Для MySQL большая и хорошо идексированная таблица равносильна смерти. Для примера - попробуйте загрузить в MySQL таблицу на 30-50 полей и объемом данных (без учета индексов) 1-2 Гб. А потом обеспечить выборку и вставку информации в реальном времени(максимальное время отклика не должно превышать 5 секунд). И "железо" тут не при чем.
Для сравнения можете также попробовать проделать аналогичную операцию с PostgreSQL (можно даже не настраивать его под конфигурацию "железа", хотя желательно).
Там, где для решения задачи хватает MySQL, хватит и grep + sed + awk (c) один мой знакомый
--
меня мало, но я в тельняшке
http://www.veldv.info
- База данных ливинтернет - основные таблицы и запросы к ним, Каждый запрос как задача. Декомпозиция сложных запросов к простым. Отказ от использования JOIN. Декомпозиция таблиц на более мелкие таблицы по критерию частоты их обновления. Ручное партиционирование. Разделение архив - свежак.
и че? ну пашет нормально, дальше что? 250гиг
почитайте иль просто скачайте гипер таблю