Что использовать? variable_set или собственную таблицу?

Главные вкладки

Аватар пользователя PanDa777 PanDa777 1 мая 2008 в 9:19

Сейчас вот пишу некий модуль. В нём требуется сделать поддержку "профилей" - то есть просто несколько возможных вариантов настроек. Что будет правильнее для этого использовать - системную таблицу variables или создавать свою собственную? Я склоняюсь ко второму...

Update:
Но, кстати, скорее всего на большинстве сайтов в этой таблице будет всего лишь одна запись... Вот и вопрос: какие минусы будут у способа с созданием собственной таблицы?

И ещё: запись нужна будет всего лишь несколько раз в сутки. Пока что...

Для чего мне всё это надо? Пишу модуль полного бэкапа с использованием только PHP - кода (насколько я понимаю, те модули, которые есть, используют утилиты коммандной строки, которые не везде доступны). Использую в нём Schema API, так что это должно получиться довольно-таки удобно...

Комментарии

Аватар пользователя PanDa777 PanDa777 1 мая 2008 в 14:08

А зачем загружать их каждый раз при обращении к старице? Я, конечно, понимаю, что всё это берётся из кеша, но всё же... Да к тому же и прямо-таки на таблицу наскребается: id + имя + путь + ещё два поля... В дальнейшем - ещё расширение... Хотя, вообще-то, по отдельности, скорее всего, они не будут, поэтому их с успехом мог бы заменить explode. В то же время пришлось бы заводить бы ещё одну переменную, отвечающую за перечесление, какие же профили были созданы... И, соответственно, в каких переменных хранятся данные... Поэтому и возник вопрос...

Аватар пользователя ucTok_Alex ucTok_Alex 15 июня 2008 в 20:14

Я бы использовал переменные.
НФБК это конечно хорошо и здорово, но если не треба делать запросы, то и реляционная БД - никчему. В друпале и без нас хватает всяких чудо запросов.
Я бы загнал в переменные в сериализованном виде

Как в рекламе: Зачем тебе весь мир, если ты туда не звониш

Аватар пользователя PVasili PVasili 1 мая 2008 в 22:13

полный бред. Было бы интересно на источник взглянуть.
Любому SQL и MySQL не исключение удобнее работать с одной большой, с хорошими индексами таблицей, чем с кучей мелких. Это аксиома SQL.

К автору: а в чем особенность модуля backup-a? Чем плох cron? Почему нельзя проверить дату создания предыдущего файла архива?
Сдаётся мне, что у вас неправильная начальная установка.

Аватар пользователя PanDa777 PanDa777 1 мая 2008 в 23:52

Да всё хорошо. Только чем конкретно его делать, если консольные утилиты недоступны? При чём тут начальная установка?

Аватар пользователя Stalker-g2 Stalker-g2 2 мая 2008 в 16:03

PVasili wrote:
полный бред. Было бы интересно на источник взглянуть.
Любому SQL и MySQL не исключение удобнее работать с одной большой, с хорошими индексами таблицей, чем с кучей мелких. Это аксиома SQL.

К автору: а в чем особенность модуля backup-a? Чем плох cron? Почему нельзя проверить дату создания предыдущего файла архива?
Сдаётся мне, что у вас неправильная начальная установка.


полный бред-это заявление PVasili по сравнению с разработчиками liveinternet.
http://www.rit2008.ru/paper_view.html?id=1797
изучайте матчасть. аксиома жизни.

Аватар пользователя mityok mityok 3 мая 2008 в 1:40

PVasili wrote:
полный бред. Было бы интересно на источник взглянуть.
Любому SQL и MySQL не исключение удобнее работать с одной большой, с хорошими индексами таблицей, чем с кучей мелких. Это аксиома SQL.

Не надо путать полноценный SQL-сервер и MySQL. Для MySQL большая и хорошо идексированная таблица равносильна смерти. Для примера - попробуйте загрузить в MySQL таблицу на 30-50 полей и объемом данных (без учета индексов) 1-2 Гб. А потом обеспечить выборку и вставку информации в реальном времени(максимальное время отклика не должно превышать 5 секунд). И "железо" тут не при чем.

Для сравнения можете также попробовать проделать аналогичную операцию с PostgreSQL (можно даже не настраивать его под конфигурацию "железа", хотя желательно).

Там, где для решения задачи хватает MySQL, хватит и grep + sed + awk (c) один мой знакомый Smile

--
меня мало, но я в тельняшке
http://www.veldv.info

Аватар пользователя Stalker-g2 Stalker-g2 2 мая 2008 в 16:03

- База данных ливинтернет - основные таблицы и запросы к ним, Каждый запрос как задача. Декомпозиция сложных запросов к простым. Отказ от использования JOIN. Декомпозиция таблиц на более мелкие таблицы по критерию частоты их обновления. Ручное партиционирование. Разделение архив - свежак.

Аватар пользователя alexandr.poddubsky alexandr.poddubsky 17 апреля 2009 в 18:40

"mityok" wrote:
ля MySQL большая и хорошо идексированная таблица равносильна смерти. Для примера - попробуйте загрузить в MySQL таблицу на 30-50 полей и объемом данных (без учета индексов) 1-2 Гб. А потом обеспечить выборку и вставку информации в реальном времени(максимальное время отклика не должно превышать 5 секунд). И "железо" тут не при чем.

и че? ну пашет нормально, дальше что? 250гиг