Как записать параметры в БД

Тема в разделе "Базы данных", создана пользователем Konpolya, 5 сен 2018.

Статус темы:
Закрыта.
Модераторы: latteo
  1. 2cher777

    2cher777

    Регистр.:
    10 мар 2018
    Сообщения:
    273
    Симпатии:
    105
    С 8й версии мускула только поддерживается?
     
  2. Black Hat

    Black Hat

    Регистр.:
    15 май 2015
    Сообщения:
    165
    Симпатии:
    110
    bobrowss и 2cher777 нравится это.
  3. metal-stroi-komplekt

    metal-stroi-komplekt

    Регистр.:
    23 дек 2012
    Сообщения:
    155
    Симпатии:
    48
    Если товаров до 5000, то все будет летать на такой структуре:
    таблица товаров: ID , бла, блабла, ...
    таблица опции: ID(int11), IDтовара(int11), ID_Тип-Опции(int11), Значение_Опции(var255)
    ну до кучи можно еще и третью таблицу, где названия опции хранить, но проще в php подставлять НАЗВАНИЕ опции согласно ТИПа опции
    Что такое ТипОпции? Это число (для экономного хранения в БД и быстрого поиска по числу!), например:
    1 - это цвет, 2 - ширина, 3 - длина, 4 - вес, ...
    В Значение_Опции соответственно пишем - голубой, или 436 или 623 или 3.400
    Это немного не по стандартам, по стандарту - три таблицы, где в 3-ей будут храниться названия опции, но на малом магазе и так попрет! Т.е. названия опции ты простопомнишь и в php их подставляешь в зависимости от ID_Тип-Опции
     
    bobrowss нравится это.
  4. bobrowss

    bobrowss Создатель

    Регистр.:
    5 апр 2018
    Сообщения:
    10
    Симпатии:
    0
    Почему только для 5000? Если привязан в использовании MySQL, то такая схема в принципе единственно верная для оптимальной работы.
     
  5. metal-stroi-komplekt

    metal-stroi-komplekt

    Регистр.:
    23 дек 2012
    Сообщения:
    155
    Симпатии:
    48
    ну потому, что будет разбухшая таблица опции,если например берем 10000 товаров да по 5 опции, то что получится- 10000 строк в таблице product и 50000 строк в таблице опций))) И при выводе странички товара придется пробегать по всей таблице опций, чтобы найти все опции товара, опции редко идут по порядку, что-то добавляют к товару позже и т.д. Вот и получается вперемешку.. Но все решает эксперимент, да и запросы конструировать всяко проще всего на такой структуре, это к бабке не ходи!)))
     
    bobrowss нравится это.
  6. bobrowss

    bobrowss Создатель

    Регистр.:
    5 апр 2018
    Сообщения:
    10
    Симпатии:
    0
    Что значит пробегать? SELECT самая малая по затратам ресурсов в MySQL насколько мне известно.
     
  7. metal-stroi-komplekt

    metal-stroi-komplekt

    Регистр.:
    23 дек 2012
    Сообщения:
    155
    Симпатии:
    48
    если голый select - наверное да. тут речь о селекте, который будет обвешан условиями...
     
    bobrowss нравится это.
  8. bobrowss

    bobrowss Создатель

    Регистр.:
    5 апр 2018
    Сообщения:
    10
    Симпатии:
    0
    SELECT обвешанный LEFT JOIN - ами скорее. Но это только позволит затрагивать несколько таблиц. Но выгода в оптимизации хранения информации думаю очевидна. У меня есть проекты с миллионами записей в таблице, никакого торможения не замечается. Сейчас ведь уже новый миллениум. Серваки уже давно мультипроцессорные)
     
  9. bettelli

    bettelli Создатель

    Регистр.:
    16 сен 2017
    Сообщения:
    28
    Симпатии:
    3
    One common mistake is assuming that MySQL provides results on demand, rather than calculating and returning the full result set. We often see this in applications designed by people familiar with other database systems.
     
  10. tizor

    tizor Писатель

    Регистр.:
    14 окт 2018
    Сообщения:
    8
    Симпатии:
    1
    Да, что в mysql, что в pgsql давно уже есть парсинг json.
     
Статус темы:
Закрыта.