Пишется скрипт универсального Каталога (товаров). (Родов товаров всего три - "обычные", "цифровые", "товары-услуги")
Есть таблица объектов/товаров. 1-я часть полей чисто "системные", и не меняются от сайта к сайту (напр. published, alias, date_add, date_update, ...). 2-я часть полей от сайта к сайту может меняться (напр. "кол-во", "отгружается в течении" "ширина/высота/длина", "вес", "налог", "артикул", "файл(вложения)", ...) Напр. у цифровых товаров, и товаров-услуг - почти всех этих полей не будет.
Хочется дать возможность пользователю менять удалять/добавлять/изменять поля 2-й части.
Поэтому можно "разорвать" основную таблицу товаров на 2-е. 1-я со "СТАТИЧЕСКОЙ структурой". 2-я с "ДИНАМИЧЕСКОЙ структурой".
(В отличии от таблиц-"Типов товаров" здесь не будет происходить РАЗРЯЖЕНИЯ таблицы. Т.е. напр. 15%процессоров, 22%ноутбуков, 17%мониторов - раскидаются по таблицам. У этих типов есть "непересекающиеся", индивидуальные атрибуты, которые и будут вынесены в отдельные таблицы. Отчего в основной таблице - станет меньше пустых полей. Здесь же, 2-я таблица это не какой то ОТДЕЛЬНЫЙ тип товара. А напротив имеет другой смысл "ОБЩИЙ набор полей - у ОДНОГО определеного сайта/магазина")
Вопрос 1. Насколько бредово так разрывать основную таблицу?
Вопрос 2. Если все же разорвать, то насколько критичным это будет в плане производительности? Если товаров станет, скажем 70-100тыс.?
Вопрос 3. Насколько это плохо, и чем чревато - давать пользователю менять структуру 1-й таблицы (являющейся как бы "входной точкой")? (Просто пометив где-то к каким полям он не имеет доступ)
Срочно читать про нормализацию таблиц и join :))) Пока каша какая-то :)))
Никакого разрежения в норме быть не должно. Ну не сможете Вы обеспечить целостность данных, каша будет. Это должно быть несколько связанных между собой таблиц. Со необходимыми ограничениями, обеспечивающими целостность данных.
Концептуально, у Вас должно быть несколько таблиц "измерений". Например, тип товара - в отдельной таблице. Имеющиеся товары с описаниями - в другой. Естественно, если таблица с описаниями будет ссылаться на таблицу типов товаров. И т.д. И одна таблица фактов. В ней то, что, кем, кому, когда было сбарыжено, например, в виде отсылок к соответствующим таблицам.
А потом собирать, собирать все join-ами.
В общем, читайте, разбирайтесь. С кашей в голове получиться может только каша. Избави Вас господь всю информацию сваливать в одну кучу.
Смотрите. Есть таблица товаров.
1. К нам стали поступать процессоры. Мы добавили в нашу таблицу 2-а поля "тактовая частота", "кол-во ядер". Так?
Теперь стали поступать мониторы. Мы добавили еще два поля "разрешение экрана", "Технология изготовления матрицы"
2. Увидили что много полей - "индивидуальных", "непересекающихся". Мы ВЫНЕСЛИ индивидуальные поля - по таблицам-"типам товара". Т.е. один тип = одна таблица. Так? (с точки зрения алгебры это - "разрежение матриц". Когда в таблице много пустых ячеек, и мы "разрядили" ее на несколько таблиц)
3. К СТРУКТУРЕ таблиц "типов товара" мы дали доступ пользавателю(админу). Т.е. он может их "конструировать" из админки. Написали кое-какой API, запилили интерфейс в админке, для манипулирования СТРУКТУРАМИ "таблиц-типов". До этого момента я думаю все понятно.
4. Посмотрели программисты универсального коробочного скрипта. И увидели что в ОСНОВНОЙ таблице - много полей которые часто не используются. Которые могут меняться от сайта-к-сайту. Напр. поля "кол-во", "отгружается в течении" "ширина/высота/длина", "вес", "налог", - не используются у цифровых товаров. И для магазинов цифровых товаров - основная таблица избыточна.
5. Появилось желание "РАЗОРВАТЬ" основную таблицу на две. И те поля которые МОГУТ меняться от сайта к сайту - ВЫНЕСТИ в "таблицу-тип". Т.е. теперь у нас появится тип товара "base". И с точки зрения архитектуры/системы она станет ТАКИМ же "типом товара".
Мы писали систему (api, интерфейс) для работы с "таблицами типами"(создание таких таблиц, манипуляция их структурой). Теперь, с таблицей "base" Мы можем делать ВСЕ что мы можем делать с "таблицей-типом".
И поймите простую вещь. Реляционная база данных и ее таблицы - это не то, что Вы там себе вообразили - куда хочу туда ворочу. Таблицы, связи между ними, ограничения, которые Вы накладываете на поля незыблемы. Эта структура не подлежит изменениям до тех пор, пока Вы не соберетесь полностью изменить дизайн. Они неприкосновенны. Табу. Если Вы хотите хранить в них какую-то ерунду, которая меняется раз от разу - храните, никто не мешает. Надо Вам туда засунуть пары значений - параметр/значение - суйте, и обрабатывайте по месту.
Вы, вот, когда в трамвае прокатиться собираетесь - как все люди входите, или, может быть, в окно лезете, или вентиляционный люк, а может, просторную дыру в его обшивке себе пробиваете?
rell_nx: Предпочел бы сначала научиться чему-нибудь, а потом делать. Вы простую концепцию освоить не можете, а говорите о более сложных. При этом читать не желаете :)))
rell_nx: В плане РСУБД напрашивается же следующее. Всю ту кучу возможных колонок надо разбить на две группы. Те принципиальные, по которым Вы собираетесь искать (делать запросы) и те, которые нужны Вам только для информации.
Пример - частота процессора. Она, очевидно, может быть как у процессора, так и у компьютера, планшета или смартфона. То, что по ней будут проводить поиск, весьма вероятно. В самом простом случае этот параметр заслуживает отдельной колонки в общей таблице. И пусть поле будет пустым для вещей, у которых процессора нет, это хорошо и удобно.
Другой случай - это габариты в упаковке, например. Ну не будет никто выбирать телефон по габаритам и весу его коробки. Такие запросы не понадобятся. Но сама информация может быть нужна. Ее можно смело сериализовать с другой такой же описательной информацией и всю кучу класть в одно поле. И доставать оттуда когда понадобится. Туда вообще можно писать что угодно - хоть температуру на Марсе. Главное, для удобства загонять туда эти данные в виде пары ключ-значение.
Например:
Температура на Марсе: 300K
Засунули пары, вытащили пары - а потом вывели где надо. До тех пор, пока значение не разлучается с ключем и не используется каких-нибудь неявных предположений о том, что в каком порядке там лежит, все вообще замечательно.
Разве это неясно? Разве есть причины насиловать таблицы или использовать какие-то извращенные базы данных с уже вместо Вас изнасилованными таблицами?
coodan: Вы тоже странное решение привели=)) Я конечно не спорю, просто почитав тему тоже любопытно. Вот например вы пишите "В самом простом случае этот параметр заслуживает отдельной колонки в общей таблице." Если задача - гипермаркет разнотипных товаров. То таких параметров, по которым проводится поиск может быть несколько тысяч. И как делать таблицу с 5-8000тыс полей?=)) ИМХО в подобной задаче нужен какой-то гибрид с NoSQL. Но это конечно просто ИМХО=))
link00: Ага, и потом плавать в этой неструктурированной штуке, которая будет выдавать что попало. Куча, куча примеров - заходишь вроде в крупный магазин, а у них два смартфона по характеристикам сравнить нельзя - потому что каждый пишет что попало и куда попало, создавая для этого все новые и новые поля. А в итоговой таблице сравнения то одного нет, то другого - а то и то же самое в разных параметрах написано.
Если база требует 8000 таких обязательных полей, то там должно быть 8000 обязательных полей, да еще и проверки вводимых значений не помешали бы. А раздолбайство в заполнении базы до добра еще никого ни разу не доводило.
coodan: Вообще если, так сказать с "математической" точки зрения, думаю Вы правы, нужна одна большая таблица. Но с практической...
1) Т.к. заранее ни кол-во типов, ни кол-во атрибутов неизвестно - мы каждый раз вмешиваемся в СТРУКТУРУ основной таблицы товаров.
2) Кол-во записей может быть огромным. Alter у таблиц с большим числом записей - это известная неразрешенная толком проблема. Он будет ложить базу МИНИМУМ на несколько часов при КАЖДОМ добавлении нового столбца. И уже задача не выполнена - т.к. изначально она подразумевает довольно динамичное добавление/удаление новых и новых столбцов.
3) В MySQL максимум 4096 столбцов на таблицу, в PostgreSQL 250-1600, в Oracle 1000
4) Если не "разрядить" эту таблицу, она будет ОГРОМНОГО размера. Вряд ли это будет оптимально в плане скорости работы с ней. Последний пункт я ХЗ тут просто мое скромное мнение=)) (Тестов таких не делал)
5)сложнее оперировать типами товаров - как самостоятельными сущностями, т.к. они "размазаны" хаотично по таблице
link00: Конечно, речи о том, чтобы походу кроить таблицу не шло. Речь шла о том, что при желании можно выделить столбцы, необходимые для поиска, остальное хранить в отдельном поле. А таблицу больше не трогать никогда (т.е. до следующей версии).
Другая альтернатива - создавать отдельные таблицы для отдельных категорий и их обрабатывать отдельно. Внутри одной категории структура таблицы очевидна.
По поводу noSQL - штука, наверное, мощная, но, согласитесь - это бред, когда школьник неспособен освоить эвклидову геометрию и кричит, что будет использовать геометрию Лобачевского - ему де евклидовы аксиомы мешают.
link00: А тут ведь так вопрос и стоит - школота SQL освоить не может и что такое нормализация не понимает - еще бы, читать то он ничего не хочет. Какой тут noSQL. Я так думаю, что noSQL для грамотных.
coodan: "А тут ведь так вопрос и стоит - школота SQL освоить не может и что такое нормализация не понимает - еще бы, читать то он ничего не хочет."
=)
"Конечно, речи о том, чтобы походу кроить таблицу не шло."
- Дак об этом и вопрос был. В том, что если это Мегамаркет товаров, то З-А-Р-А-Н-Е-Е ни типы ни атрибуты НЕИЗВЕСТНЫ. Раз типы неизвестны то и поля по которым будет осуществляться поиск/сортировка/сравнения - тем более заранее неизвестны. Не о жесткой структуре речь. (У меня сейчас подобное в скрипте Агентства Недвижимости, но там попроще правда.)
"Другая альтернатива - создавать отдельные таблицы для отдельных категорий и их обрабатывать отдельно. Внутри одной категории структура таблицы очевидна. "
- Ну т.е. создавать таблицу на каждый Тип товара так? И разрывать(разряжать) основную? Дак об этом ТС и пишет
"По поводу noSQL - штука, наверное, мощная"
- Дело не в мощности. Первична РЕАЛЬНАЯ ЗАДАЧА. И здесь задача - это динамичные, изменчивые метаданные. Инструмент - вторичен. Применяются эти вещи взависимости ОТ ЗАДАЧИ. Не по принципу что мощнее/не мощнее=)) Да и степень нормализации зависит от реальных задач и внешних факторов. Не по принципу "как это математически красивее"=))
Когда Э.Кодду этот вопрос задали на его первой презентации РБД он ничего ответить не смог. Это один из ортодоксальных недостатков РБД - проблемы с динамичными метаданными.
link00: Не вижу связи. Если мы создаем отдельные таблицы для отдельных категорий, то о какой вообще основной таблице идет речь? Ее не будет. Если мы ее хотим иметь, то должны четко определиться с теми полями, которые принципиальны для поиска. По ним она будет разрежена, ибо они будут не у всех товаров. Что непринципиально для поиска - сериализовать.
По поводу изменчивых данных - так ведь не так-то они и изменчивы. И не могут быть изменчивы. Не должны. Иначе получается описанный мной позор - два смартфона сравнить нельзя - из-за того, что изменчивость прикручена там, где ею и пахнуть не должно. Фейспалм.
link00: И по поводу 8000 или 8000000 полей. Там, где они объективно нужны, нужна СУБД, которая их поддерживает. Даже если ее самому писать придется. Только где они объективно нужны? Для интернет-магазина?! Зачем?!
Простой
Средний
