| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > [MySQL] Структура базы для сайта |
| Автор: VingradFan 9.1.2009, 18:53 |
| Всех приветствую. Подскажите, пожалуйста, как организовать хранение данных о пользователях... Суть проблемы такова, что поля в таблице 'users' будут заводиться все новые и новые в процессе модификации сайта. На сколько мне ивестно, MySQL позволяет произвести всего навсего 200 модификаций структуры таблицы, это ничтожно мало для наших задач.... Пришла в голову идея организовать таблицу параметров id | param | value ---------------------- 1 | name | Vasya 1 | pass | 2о4л2 1 | email | [email protected] ................................... /* очень много строк */ 1 | color_theme | red думаю, идея понятна, но рационально ли это? Посоветуйте, что-нибудь, пожалуйста! Спасибо! |
| Автор: Wolf1994 9.1.2009, 19:53 |
| IMHO, если и есть такое ограничение, проще перевоссоздать таблицу с нуля, заполнить данными из прежней таблицы и получить ещё+200 модификаций, при этом использовать MySQL так, как он и должен быть использован. |
| Автор: VingradFan 9.1.2009, 20:34 |
| Wolf1994, спасибо за мнение! То-есть, Вы считаете, нерациональным такой подход? |
| Автор: Wolf1994 9.1.2009, 23:05 |
| Я бы не стал его использовать, потому что мне нужна быстрая выборка по любой колонке. Также при стандартном подходе точнее определены типы колонок и их длины, что также, наверное, отражается на производительности. |
| Автор: VingradFan 10.1.2009, 00:02 |
| Wolf1994, благодарю |
| Автор: LSD 10.1.2009, 03:15 |
| Извиняюсь за грубость, но это полный бред! Это же как надо подходить к разработке, чтобы еще на этапе начального проектирования допускать возможность внесения более 200 модификаций в продакшн базу? Плюс ко всему, ~200 полей в таблице. Вы вообще про нормализацию что нибудь слышали? |
| Автор: VingradFan 10.1.2009, 15:46 | ||||||
Извиняю
Предпочитаю не врать на пустом месте, поэтому отвечу: "Не слышал ".UPD почитал немного, теперь слышал
Объясняю: "Пишется CMS. CMS должна, по моему мнению, быть рассчитана на неограниченное количество добавочных копонентов. Каждый компонент записывает в базу юзверей несколько персональных настроек самого себя. Отсюда такое количество правок ". |
| Автор: LSD 10.1.2009, 16:46 | ||
Вы там хотите, прям из кода CMS DDL выполнять что ли? |
| Автор: VingradFan 10.1.2009, 17:14 | ||||||
ээээм.... ну разумеется что за вопрос?
CMS будет выполнять различные запросы к БД. В этом же и суть CMS |
| Автор: LSD 10.1.2009, 17:18 | ||||
Ты уверен, что внимательно прочитал цитируемый текст? DDL это не запросы, это создание/модификация/удаление таблиц. Ты хочешь прям в коде выполнять alter table? |
| Автор: VingradFan 10.1.2009, 17:49 |
| LSD, да, я хочу прям в коде выполнять alter table а что в этом такого? |
| Автор: LSD 12.1.2009, 14:43 | ||
Это очень и очень плохая практика. Использование DDL потенциально может создать кучу проблем в базе. DDL операторы очень ресурсоёмкие и могут приводить к обиширным блокировкам в базе. Операции DDL выполняются вне транзакций, а значит если одна из серии пошла не так, то "вернуть как было" не получится. Будут большие проблемы с оптимизацией. Проблемы с репликацией данных. Невозможность полноценно использовать вьюхи и хранимые процедуры. Проблемы с бекапом/восстановлением данных. Специфичные для каждой СУБД проблемы, например тот же Оракл потребует перекомпиляции всех процедур которые используют изменившуюся таблицу, или ограничение MySQL на количество модификаций и т.п. Плюс понадобится вводить ещё какие-то словари которые бы хранили информацию о том, какие поля были добавлены и куда, да еще отслеживать чтобы эти словари были в актуальном состоянии. И самое главное не знаешь где встретишь грабли. В общем: в нормальных системах так не делают. По поводу проектирования: вначале добавляешь таблицы для тех параметров которые должны быть изначально. Для сущностей которые нуждаются в задаваемых пользователем вводишь две таблицы: типы_параметров[ид, имя, и т.п.] параметры[ид, ид_типа_параметра, ид_родительской_сущности, значение_параметра] |
| Автор: Бонифаций 16.1.2009, 09:10 | ||
Откуда дровишки? |
| Автор: VingradFan 17.1.2009, 23:18 | ||||||
LSD,
в этом ограничении и суть темы
это решение я написал в заглавном посте... товарищ сказал, что не айс как-то расходятся мнения, друзья
вот это вообще не понял  что за словари? зачем? каждый компонент читает из базы только свои параметры, которые ему нужны для работы...Бонифаций, информация от одного гуру IT LSD, Бонифаций, спасибо а ответ |
| Автор: LSD 19.1.2009, 16:01 | ||||||
Откуда твой код узнает какие колонки в таблице есть, и какие из этих колонок ему нужны?
Сейчас ты столкнулся с этим ограничением, завтра с другим, и так и будешь идти по граблям.
Не айс, это не аргумент, пусть аргументирует. |
| Автор: VingradFan 19.1.2009, 20:10 | ||||||
странный вопрос каждому компоненту на стадии создания говорится, какие колонки вставить, и соответственно только из них и читать данные но не в том суть темы...
вот собсно аргументы
Я для себя решил остановиться именно на таблице параметров... LSD, спасибо за совет.... |
| Автор: sneer 21.1.2009, 22:18 |
| делаешь таблица опции - ай-ди опции, имя опции дальше вставляешь в к клиента ай-ди опции и значения. как-то так каждый раз альтерить тейбл это бредятина. Приведи хотя бы три примера действий когда ты хочешь делать альтер тейбл. |
