Правильная структура БД

Тема в разделе "Программирование", создана пользователем DKraev, 18.09.2011.

  1. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
    Здравствуйте. Возникла необходимость доработать Virtuemart, а именно...

    Нужно сделать список значений товара. Этот список должен быть редактируемым. Сразу оговорюсь, что стандартный функционал не подходит.

    Примерно так я себе это представляю: Заходим в Вирт, там есть уже добавленная дополнительная ссылочка "Свойства товара". Переходя по этой ссылке мы видим перечень свойств, который можем отредактировать, удалить или добавить новое свойство (вес, высота, глубина, ширина, степень идиотизма и т.д...). Отредактировать можно название свойства и степень измерения (кг., мм, см и т.д).

    Добавляем, к примеру, свойства: Вес и Ширина. Далее открываем любой товар и на заранее созданной дополнительной вкладке видим перечень добавленных свойств и можем указать свои значения.

    Сама реализация более-менее ясна. Вопрос стал в том, как правильно организовать структуру БД, если можно так выразиться.

    Я рассматривал такие варианты:

    Вариант 1.

    Создаём таблицу jos_vm_param, такого вида:

    param_id | param_name | param_izm
    ------1------|----------Вес----|-------кг
    ------2------|--------Длина--|-------мм

    И вторую табличку, например jos_vm_param_prod куда пишем значения:

    param_id | prod_id | param_atr
    -----1-------|-----138--|-----1.5
    -----2-------|-----138--|-----400

    Ну и так далее. Приемлем ли такой метод?


    Вариант 2.

    Писать всё в одну таблицу jos_vm_product_param, например так:

    prod_id | param_ves | param_dlina | param_stepen_idiotizma
    ---138----|-----1.5 кг---|-----400 мм--|---------------10%
    ----24-----|-------3 кг.--|-----1.5 м-----|--------------- 40%

    Т.е в данном случае при добавлении нового свойства мы просто добавляем столбец в данную таблицу, a когда заполняем данные для продукта, то эти столбцы, соответственно заполняем.

    Каким путём будет правильней пойти? Вторым?

    UPD: Сейчас сижу, читаю что написал и понимаю, что второй вариант не подходит... Куда я буду писАть наименование параметра?
     
    Последнее редактирование: 18.09.2011
  2.  
  3. woojin
    Offline

    woojin Местный Команда форума

    Регистрация:
    31.05.2009
    Сообщения:
    3 209
    Симпатии:
    335
    Пол:
    Мужской
    лучше использовать первый вариант - я так думаю!!!
     
  4. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
    Привет, woojin, давно не виделись ))
    А как думаешь, не сильно нагрузит БД? ведь если параметров будет 10, к примеру, то для каждого продукта нужно будет сделать 10 записей. Если продуктов 500, то это уже 5000 записей в БД. Потом же нужно будет их все перебрать, чтобы вывести для каждого продукта свои значения во flypage
     
  5. woojin
    Offline

    woojin Местный Команда форума

    Регистрация:
    31.05.2009
    Сообщения:
    3 209
    Симпатии:
    335
    Пол:
    Мужской
    привет!!;)
    а работу VM анализировал?
    там знаешь сколько перекрёстных таблиц?!
    так что не парься с этим, ну увеличится у тебя запрос на 0.0005 секунды
    и будет так увеличиваться какждые к примеру 1000 записей - сильно ты таким сервер не нагрузишь, у него всё равно минимум время ожидания отклика 60 секунд, а у VM (с его перегруженными запросами) время обращения к БД примерно 3-5 секунд МАКСИМУМ

    я такую нагрузку видел не на очень хорошем (но дешевом) хостинге при условии что в БД было порядка 8-9 тысяч товаров, а эти самые товары импортировались из 1С примерно 2.5 секунды

    так что делай и не мучайся
     
    DKraev нравится это.
  6. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
  7. Offline

    Legolazzzzz Недавно здесь

    Регистрация:
    02.06.2010
    Сообщения:
    25
    Симпатии:
    1
    Пол:
    Мужской
    Есть 3й, мене поворотливый вариант.
    param_name|param_izm|prod_id |param_atr
    ---------Вес-----|-------кг-------|-----138--|-----1.5-----
    --------Длина--|-------мм-----|-----138--|-----400----

    Не думаю, что его можно рассматривать как серьёзный.
     
    DKraev нравится это.
  8. woojin
    Offline

    woojin Местный Команда форума

    Регистрация:
    31.05.2009
    Сообщения:
    3 209
    Симпатии:
    335
    Пол:
    Мужской
    gft, о кстати у Legolazzzzz, хорошее предложение, кстати можешь попробовать это возможно будет лучшим вариантом
     
  9. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
    Рассматривал. В варианте Legolazzzzz придётся каждый раз писать в базу param_name и param_izm. И потом, как добавлять новые параметры? Сразу прописывать для продукта, с нулевыми значениями? Мне кажется, это чересчур громоздко.

    Уже практически сделал всё, остался один момент. Как отследить нулевое значение отправляемое из input?

    Есть поле для ввода значения параметра. Если в поле введены данные, то записать их в базу. Если данные не введены, то удалить имеющуюся запись. Завис именно на условии if и else. НЕ могу сообразить что прописать для "if".
     
  10. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
    Угу, причина, то оказывается была совсем в другом... Решено.
     
  11. woojin
    Offline

    woojin Местный Команда форума

    Регистрация:
    31.05.2009
    Сообщения:
    3 209
    Симпатии:
    335
    Пол:
    Мужской
    а по умолчанию NULL в поле тебя не устраивает?

    ну можно же использовать и switch () .... case
     
  12. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
    Нет. Я не сторонник того, чтобы хранить пустые, неиспользуемые записи в базе.

    Например, если в одном товаре будут использоваться параметры Вес, Длина и Ширина, а в другом они не будут использоваться вообще никогда, то в случае Legolazzzzz всё равно придётся их хранить в базе со значением NULL.

    Это, конечно, не сыграет большой роли, но тем не менее это неправильно ))
     
  13. woojin
    Offline

    woojin Местный Команда форума

    Регистрация:
    31.05.2009
    Сообщения:
    3 209
    Симпатии:
    335
    Пол:
    Мужской
    в БД вообще много в каких таблицах храниться NULL и ничего!!!
    его вариант менее затратен на дисковое пространство и на процессорное время для поиска и "выцепляния" нужных данных, нежели если сделать две таблицы и потом их соединять запросом

    ну думать тебе - но мнения ты слышал!!!
     
  14. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
    Мог бы поспорить. Дисковое пространство тут вообще роли никакой не играет, т.к. база занимает минимум пространства по сравнению с файлами. А по времени - две таблицы используются только в админке, когда мы добавляем параметры для товара. Соответственно нагрузка здесь кратковременная и тоже не страшна, по сути - любой хостинг справится.

    Как вариант - имеет место быть, возможно кто-то бы сделал именно так, но мне, после обдумывания и рисования схемы на бумаге, показался более удобным именно первый вариант.

    Согласен, я и не говорю что это критично. Но более правильно - не хранить пустые значения. Просто потому, что они не нужны и нигде не используются...
     
  15. Offline

    mazur Недавно здесь

    Регистрация:
    06.01.2010
    Сообщения:
    56
    Симпатии:
    6
    Пол:
    Мужской
    Вариант Legolazzzzz может иметь место. Создается поле params (на примере таблицы jos_users) и там перечисляются нужные параметры. В ядре есть методы специально сделанные для создания и разбора этих полей. Сейчас не вспомню, но что-то вроде setParams и getParams. Но не считаю этот вариант правильным, т.к. если после заполнения 10 000 товаров захочется поменять название параметра с Степень Идиотизма на Степень Дебилизма, придется переписывать всю таблицу. А во втором варианте нужно будет изменить всего лишь одну запись.
     
  16. DKraev
    Offline

    DKraev <i>(aka gft)</i>

    Регистрация:
    16.08.2008
    Сообщения:
    1 627
    Симпатии:
    216
    Пол:
    Мужской
    В первом варианте нужно сменить лишь одну запись, чтобы поменять имя параметра. Собственно, по нему и было сделано ))
     
  17. Offline

    mazur Недавно здесь

    Регистрация:
    06.01.2010
    Сообщения:
    56
    Симпатии:
    6
    Пол:
    Мужской
    О, да. %). Пора спать. Имел ввиду первый вариант.
     

Поделиться этой страницей

Загрузка...