В скрипте каталога изображения товаров именуются по маске {id}{alias}{№}.{ext}. Возникает вопрос, стоит ли вообще делать поле в таблице products для изображений? (они ведь именуются по строгому шаблону) Какие могут быть подводные камни/нюансы.
Есть важный нюанс - это коробочный скрипт. Могут быть ведь нюансы с файловой системой, обращением к ней, импортом/экспортом, синхронизацией с ERP, и т.д.
Привет.
Что посоветуете использовать?
Читал кое какой материал и сложилось двоякое мнение.
Где-то хвалят PostgreSQL, где-то MySQL, но больше люди склоняются к PostgreSQL по некоторым причинам.
Некоторые из причин:
1. PostgreSQL следует современным стандартам SQL
2. В PostgreSQL механизм репликации лучше чем в MySQL (что то связано с физической и логической репликацией)
3. Всё, чего нет в PostgreSQL и есть в MySQL будет реализовано в будущем, в рамках разумного
Так следует ли взять PostgreSQL за основу для мало- или средне-нагруженных проектов?
Обыдна что в MySQL нэт аналога hstore PostgreSQL Иногда, не хватает нативно этой штуки..
Частенько натыкался на то что NULL стоит избегать. Теорию то я знаю. И чем он от пустой строки отличается, и то что это 1 дополнительный бит. и пр. Естесно применять от задачи следует. Вопрос как на практике, эти опасения может уже не актуальны, и/или СОВЕРШЕННО малозначительны?
Жесть Я рассуждаю когда вот проблема хай-лоада может стать не актуальной в вебе, для большинства крупных сирвисов? 13лет назад вспомнить смешно какое было железо. Лет через 15-20 мой вопрос "плодить ли таблицы" тоже был бы наверно не актуален=)
взять пример из первого поста DeepVarvar, но не советует все типы (text, decimal) хранить в одной таблице. А для каждого типа сделать свою. ИМХО
+ Места меньше, индексы более вменяемы
К этому варианту я сначала и склонялся. Но фишка в том, что 1)Запросы будут проще если таблица одна 2)Про место понятно(в одной таблице будет много пустых ячеек), НО это таблица практически ни у кого не будет огромной, ну предел неск-ко тысяч записей, это ведь уникальные наборы значений. Исключения могут быть, но здесь мы идем по среднестатистическому магазину, а у него не много уникальных наборов значений.
Там нужно время, надо ведь не просто таблички понаделать. Надо именно сравнить работу с одной таблицей(когда все они запиханы в одну таблицу). Плюс ряд разных запросов более "естественных" протестить. Но я еще вернусь и подолблю эту тему=) А пока было решено для атрибутов не создавать отдельные таблицы. А хранить их все в одной таблице, но со столбцами по типам "int" "text".
LIME пишет:
Anchor рекомендую послушать туарега
Ну форумчанин tuareg советует избежать в этом случае* создания мелких таблиц на каждый атрибут? Верно я понял? Аргумент - скорость. Вместо этого хранить их (уникальные значения атрибутов) в одной таблице
в этом случае* Я понимаю прекрасно что "серебрянной пули нет", и что все зависит от ситуации. Реал понимаю. В погоне за универсальностью мы приобретаем проблемы с быстродействием и сложностью системы. Это проблемы - ВСЕХ универсальных систем. Просто абстрагируемся от этого=) Есть бассейн, вода втекает/и вытекает. А что там СНАРУЖИ бассейна - насос работает, или мифический Евпидокл льет, по барабану=) Такова постановка задачи, в данной теме - универсальный скрипт Каталога/Магазина.
не сумеет обработать такое колво таблиц...обещаю тебя обманули
Один запрос к БД, не будет, как правило обращаться и к 10% таблиц атрибутов. Но как я понял не в этом проблема, а в работе СУБД с information schema.
LIME пишет:
любой сервак уйдет в аут только по прерываанию запросов
Ясно. Вообщем вывод. Лучше использовать не кучу таблиц а запихнуть все в несколько таблиц (по типам _int _text) по твоему? Или все же таблицы на каждый атрибут, но в последствие, если их кол-во будет столь велико, решать эту проблему шардированием?
LIME пишет:
нафига я рассказываю дураку о шардировании?
Ко мне обращение? Одни любезности=) Я никого не оскорблял=)
такого количества таблиц нет ни у одного супер нагруженного сервиса
а ты уверен что у тебя есть такое колво таблиц?
имхо комп ляжет от одного колва
Допустим есть ИМ гипермаркета. Типов товаров - будет много. Атрибутов - еще больше. Если для каждого атрибута (для которого есть уникальный набор значений, например размеры для одежды XL,XM; материал - "хлопок", ""пластмасса", "Дигидро-альфа-эргокриптин"") будет создаваться своя таблица, то таблиц может быть больше тысячи - запросто.
LIME пишет:
огромное кол-во таблиц(скажем 3-6тысяч?)
любой сервер при таком количестве таблиц ляжет гарантировано
Понятно. На другом форуме, вроде опытный чел пишет что для СУБД - десятки тысяч таблиц не проблема http://c2n[dot]me/3gDoW8x Надо короче делать тесты=)) Но они все равно будут, собака, синтетические.
UPD: Да кстати, ВАЖНОЕ замечание. Таблицы все эти будут (как правило) содержать небольшое кол-во записей. Т.е. уникальных значений атрибутов(кол-во размеров напр., материал) как правило - мало, десятки, сотни.
[quote=LIME][/quote]
Да меня просто один человек взбаламутил, мол тебе для этой темы http://forum.php.su/topic.php?fo...8&topic=5742 цитата "надо брать СУБД с поддержкой RDF" (инструмент/модель для неструктурированных данных) Только путного на русском ничего не нагуглилось, вот и решил поинтересоваться=)) Сталкивался ли кто с этим
Сорри может вопрос тупой=) Просто на русском ничего толком не нагуглилось по этой теме. Собственно вопросы. Имел ли кто-то с этим дело? Можете ли объяснить основные моменты? Это случаем не аналог hstore PosgreSQL?
ну тогда юзать NoSQL решения/ Вот здесь на англ.
http://stackoverflow[dot]com/questio[dot][dot][dot]and-alternatives
Вообще я пришел к тому, чтобы использовать в будущем гибрид(в тех случаях когда с MySQL будут напряги), MySQL + NoSQL, вообщем 2-е СУБД.
LIME пишет:
NoSQL очень специфичное решение
+10! БД эта самый фундамент. Надо тщательно его выстроить, иначе потом сама же технология может загнать в тупик. Рекомендую статью http://habrahabr[dot]ru/post/231213/ Заголовок конечно "желтый", но статья полезная. Я ее внимательно прочитал, обратите внимание на самый последний абзац "Найдите ценность"
Не, не будет долго. Да и пофиг, если честно, главное, что бы другие операции не тормозили. Другое дело, что большинство такие "скрипты" будет юзать на хостингах, где только MySQL и есть, а там не знаю как с этим обстоит ;) Вероятно плохо ;)
А для какого кол-ва записей приемлемо? Просто я читал, (да и сам немного тестил), что alter для большого кол-ва записей долго выполняется. http://habrahabr[dot]ru/post/121129/ А то может эта проблема была актуальна 4 года назад=))
UPD: Ну да, MySQL=)
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 57
Я рассуждаю когда вот проблема хай-лоада может стать не актуальной в вебе, для большинства крупных сирвисов? 13лет назад вспомнить смешно какое было железо. Лет через 15-20 мой вопрос "плодить ли таблицы" тоже был бы наверно не актуален=)
Повлияет ли на скорость работы MySQL огромное кол-во таблиц(скажем 3-6тысяч?) Может ли это стать критичным?
