ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Связи, ключи, методы хранения
14 сообщений из 14, страница 1 из 1
Связи, ключи, методы хранения
    #38620956
Goror
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goror
Участник
Есть таблица к примеру товаров и их свойств, свойств может быть примерно 100-200 (через разделитель), поле товаров "Уникально", поле свойства периодически обновляется, добавляются новые свойства.

Я вот сейчас думаю, нормальна ли такая конструкция? Может для "svoistva" создать отдельную таблицу?

Вопрос заключается в том, что будет работать быстрее, 1 таблица хранящая всю информацию в себе, или несколько таблиц соединённых LEFT JOIN-ами и тд.

Просто мне не очень нравиться этот подход, хранить данные через разделитель, хотя в некоторых случаях, наверно, это разумно.


Код: html
1.
2.
3.
4.
5.
id  | tovar |  svoistva
-----------------------------
1   |  XXX  | 890,60,7,135,5435346
2   |  YYY  | 35,10,567564,
3   |  ZZZ  | 224,5678,63454566
...
Рейтинг: 0 / 0
22.04.2014, 00:14:12
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38620991
biwed.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
biwed.ru
Гость
Goror,
Добрый день.
Вообще я за второй вариант:
Gororнесколько таблиц соединённых LEFT JOIN-ами и тд
1. Он легко приводится к первому при помощи group_concat.
2. Думаю, что второй вариант выгоднее отличается от 1, так как с JOIN проще сопровождать. Все же Mysql реляционная СУБД.
3. Вопрос уже поднимался на форуме http://www.sql.ru/forum/1090379/proverka-peresecheniya-dvuh-mnozhestv-na-letu
4. В популярных продуктах (к примеру 1С) хранят именно через несколько таблиц. Когда разбирался с динамическими свойствами товара в 1С то составил схему www.biwed.ru/index.php/dobryaki/16-sql/39-work-with-regestry
5. Если вдруг станет вопрос про, то какие свойства изменились, то тут вы без доп. таблиц не сможете ответить.
6. В данном случае обновлять изменение свойства в разных таблицах проще, чем в одной (головняк с составлением строки для обновления).

Не понятен и вопрос:
GororВопрос заключается в том, что будет работать быстрее
Если вас интересует простой select * from t1, где t1 (ваша таблица), то он всяко будет быстрее работать, чем JOIN c group_concat. :)

С уважением,
biwed.ru
...
Рейтинг: 0 / 0
22.04.2014, 02:57:07
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38621573
Goror
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goror
Участник
biwed.ru,

В целом согласен, в конечном итоге, манипуляции с данными (через разделитель), станут более затратными и сложными в реализации, чем соединение через JOIN-ы нескольких таблиц.

Хотя (наверно) в случае с точечными выборками из таблицы, удобнее было бы работать с одной таблицей, одним полем.
...
Рейтинг: 0 / 0
22.04.2014, 14:30:52
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38622207
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
Gororнормальна ли такая конструкция?Нет.
...
Рейтинг: 0 / 0
22.04.2014, 21:24:57
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38622515
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
AkinaGororнормальна ли такая конструкция?Нет.

+1
...
Рейтинг: 0 / 0
23.04.2014, 09:50:55
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38622523
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
автор
Я вот сейчас думаю, нормальна ли такая конструкция?

ненормальна. Это нарушение 1-ой нормальной формы рел. таблицы -- тягчайший грех для
проектировщика реляционной БД.

автор Может для "svoistva" создать отдельную таблицу?

Непременно, и чем скорее, тем лучше.


авторВопрос заключается в том, что будет работать быстрее, 1 таблица хранящая всю информацию в себе, или несколько таблиц соединённых LEFT JOIN-ами и тд.


Проблема не в том, что будет работать быстрее, а в том, что будет вообще работать.
При нарушении 1НФ данные в этом поле невозможно обрабатывать с помощью SQL вообще.
Это можно делать только внешними по отношению к БД средствами, грубо говоря, в клиентской программе.


авторПросто мне не очень нравиться этот подход, хранить данные через разделитель, хотя в некоторых случаях, наверно, это разумно.


Правильно, что тебе не нравится.
И ни в каких случаях это не может быть разумным.
...
Рейтинг: 0 / 0
23.04.2014, 09:59:01
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38623009
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex564657498765453
Участник
MasterZivавторЯ вот сейчас думаю, нормальна ли такая конструкция?

ненормальна. Это нарушение 1-ой нормальной формы рел. таблицы -- тягчайший грех для
проектировщика реляционной БД.

автор Может для "svoistva" создать отдельную таблицу?

Непременно, и чем скорее, тем лучше.


авторВопрос заключается в том, что будет работать быстрее, 1 таблица хранящая всю информацию в себе, или несколько таблиц соединённых LEFT JOIN-ами и тд.


Проблема не в том, что будет работать быстрее, а в том, что будет вообще работать.
При нарушении 1НФ данные в этом поле невозможно обрабатывать с помощью SQL вообще.
Это можно делать только внешними по отношению к БД средствами, грубо говоря, в клиентской программе.


авторПросто мне не очень нравиться этот подход, хранить данные через разделитель, хотя в некоторых случаях, наверно, это разумно.


Правильно, что тебе не нравится.
И ни в каких случаях это не может быть разумным.

про дерево в базе ввиде списка пути слыхали?:) вот пример когда денормализуються данные ради производительности... (привожу не свой пример ...взял со стороны)
...
Рейтинг: 0 / 0
23.04.2014, 13:51:12
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38623455
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cygapb-007
Участник
alex564657498765453про дерево в базе ввиде списка пути слыхали?:) вот пример когда денормализуються данные ради производительности... (привожу не свой пример ...взял со стороны)Не надо путать атомарность и нереляционность
Атомарность (1НФ) гарантирует, что содержимое поля таблицы в запросах всегда рассматривается как единое целое. С этой позиции поле, содержащее полный список пути для построения дерева, - вполне себе атомарная величина.

И наоборот, все проблемы обычно начинаются с попыток разбора поля, содержащего сложносочиненное наполнение, и вычленения атомарных значений из него для использования их в реляционных запросах, что и демонстрирует нереляционность архитектуры базы данных
ничо так завернул :)
...
Рейтинг: 0 / 0
23.04.2014, 17:10:02
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38623577
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
alex564657498765453про дерево в базе ввиде списка пути слыхали?:) вот пример когда денормализуються данные ради производительности... (привожу не свой пример ...взял со стороны)

Денормализация и ненормализированность -- разные вещи.
К тому же, тут речь о 1НФ, т.е. тут проблема на грани возможности обрабатывать данные в БД вообще.
...
Рейтинг: 0 / 0
23.04.2014, 18:27:09
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38623991
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
для извращенцев
назовем это z_table
Код: html
1.
2.
3.
4.
5.
id  | tovar |  svoistva
-----------------------------
1   |  XXX  | 890,60,7,135,5435346
2   |  YYY  | 35,10,567564,
3   |  ZZZ  | 224,5678,63454566



сделаем
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
FUNCTION compare(a varchar(255), php varchar(255))
  RETURNS int(11)
BEGIN
  SET @ss = 0;
  SET @a = a;
  SET @php = php;
  SELECT
    ISNULL(GROUP_CONCAT(id)) INTO @ss
  FROM (SELECT
      id
    FROM (SELECT
        @index := INSTR(@a, ','),
        @id := SUBSTRING_INDEX(@a, ',', 1) AS id,
        @a := SUBSTRING(@a, IF(@index, @index + 1, 0))
      FROM (SELECT
               @a) AS init,
           [table_with_many_rows]
      WHERE LENGTH(@a) > 0) AS arr
    WHERE FIND_IN_SET(id, @php) > 0) AS ss;
  RETURN @ss;
END


необходимо получить из z_table записи в которыз есть значения 10,35
Код: sql
1.
2.
3.
SET @d='10,35';
SELECT id,tovar FROM(
SELECT id,tovar,compare(svoistva,@d) AS cc FROM z_table ) xx WHERE xx.cc=0


это всё в продолжение темы Проверка пересечения двух множеств на лету
...
Рейтинг: 0 / 0
24.04.2014, 09:24:15
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38624006
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
как вариант
Код: sql
1.
SELECT id,tovar,compare(svoistva,@d) AS cc FROM z_table WHERE compare(svoistva,@d)=0



в первом варианте происходит обработка 2 селектов, что при большом объёме таблицы может вызвать кеширование на диск результатов первого внутреннего селекта - это верное утверждение?

во втором варианте двойной вызов функции compare - ?
или второй раз будет вызван только результат?
...
Рейтинг: 0 / 0
24.04.2014, 09:35:57
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38624020
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
вот так будет правильно :)
Код: sql
1.
 SELECT id,tovar FROM z_table WHERE compare(svoistva,@d)=0;



ЗЫ
может потребоваться отображать совпадающие значения, и сортировать по количеству совпадений...
это любителям извращений - самим разбираться....
...
Рейтинг: 0 / 0
24.04.2014, 09:53:22
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38624032
biwed.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
biwed.ru
Гость
вадя,
Добрый день.
Может не надо учить плохому?
Попросил же человек помощи на этапе проектирования. Вроде как удалось уговорить на JOIN. :)

PS. Хотя код почитать было интересно. Слава богу, что в своих проектах использую нормальные формы.

С уважением,
biwed.ru
...
Рейтинг: 0 / 0
24.04.2014, 10:00:06
| Ответить | Цитировать | Написать  
Связи, ключи, методы хранения
    #38624056
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
biwed.ru,

я ж написал - для извращенцев
а так - для тренировки
...
Рейтинг: 0 / 0
24.04.2014, 10:20:12
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Связи, ключи, методы хранения
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&fpage=180&tid=1834931]:
 0ms
get settings:
 7ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 25ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 53ms
get tp. blocked users:
 1ms
others: 224ms
total:  337ms
созд. / загр.: 337ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]