- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Планируется проект с неплохой посещаемостью (порядка 100 тысяч хитов в сутки). В основе лежит предоставление доступа к объектам, имеющим ряд свойств с ограниченным числом значений. Что-то вроде:
Яблоня
Сорт: раннеспелый, позднеспелый, скороспелый.
Вкус плодов: сладкий, кислый, горький, соленый.
Цвет плодов: зеленый, желтый, красный, синий.
Кошка
Порода: персидская, чеширская, египетская.
Окрас: палевый, дымчатый, в яблоках, в грушах.
Характер: стойкий, нордический, ласковый, буйный, агрессивный.
Вопрос: как это дело лучше хранить для минимизации нагрузки? Сериализовать ли массивы со свойствами и помещать все в одну таблицу или же в раскидывать по трем связанным таблицам?
Николай В., ко-во значений будет фиксированное? Например,
Вкус плодов: сладкий, кислый, горький, соленый
По трем таблицам гибче и по скорости не будет хуже.
А какой поиск будет по данным? А как они будут отображаться?
ко-во значений будет фиксированное?
Неа, не фиксированное.
А какой поиск будет по данным? А как они будут отображаться?
В большинстве случаев (около 90%) будет выбираться одно значение для каждого свойства + общее число доступных значений:
Кошка
Порода — персидская (всего: 3).
Окрас — палевый (всего: 4).
Характер — стойкий (всего: 5).
В 10% данные отображаются целиком. Для редактирования, например.
Николай В., все зависит оттого, по каким полям будет вестись поиск и как часто будет обновляться структура и сами данные. уточните этот момент.
Все счетчики в отдельной таблице или целиком дерево в сериализованном массиве.
Статистика - аналогично.
Если поиск по свойствам не нужен - занумеровать значения и паковать в 1 поле.
Если выборка одним запросом кошек и яблок вперемешку не предусматривается, то в разные.
Архитектура базы в большей степени зависит от того, как будут выбираться записи, а не сколько свойств у объекта.
Про поиск так и не написали.
Я бы сделал так:
Есть одна таблица
main :
main_id
main_descr
к ней крепится еще одна таблица в которой есть поля
ex:
ex_id
ex_type
main_id
ex_value
___
Тогда все кладется на ура
main
main_id = 1
main_descr = "Кошка"
main_id = 2
main_descr = "Яблоня"
____
ex:
ex_id = 1
ex_type = 'Сорт'
main_id = 1
ex_value = 'раннеспелый'
ex_id = 2
ex_type = 'Сорт'
main_id = 1
ex_value = 'позднеспелый'
ex_id = 3
ex_type = 'Сорт'
main_id = 1
ex_value = 'скороспелый'
ну и так далее.
так проще всего.
И еще я вообще отказался от MYSQL
долгий он
Я перешел на SQLITE (http://sqlite.org), он быстрее.
Кто со мной будет спорить, скажу сразу - опыта у меня работы с базами данных - 6 лет.
Сижу на оракле, но для веба предпочитаю использовать лайт, так как есть много причин - например: установка, скорость работы,
Да я согласен, в ней нет поддержки пользователей, так именно из за этого она и быстрее =) .
Хотя это мое личное мнение, я не настаиваю, просто рассказал. как бы сделал я.
А так если У вас вопросы по БД. милости прошу. я с рабостью Вам расскажу =)
AlienZzzz, классический оракловский подход ;)
Но согласен - это наиболее гибкий и быстро расширяемый вариант.
Имея обычный выделенный оракловский сервер, действительно ничего не будет тормозить.
А вот расшаренный mysql с нагрузкой 100 запросов в секунду торопиться не будет.
Sqlite при таких нагрузках просто вызовет коллапс сервера.
По трем таблицам гибче и по скорости не будет хуже.
Будет!
В mySQL каждый join увеличивает время выполнения запроса примерно на 30%.
Проверено неоднократными тестами.
Оптимальная структура скорее зависит от частоты обновлений\добавлений данных. Разумное дублирование значительно ускоряет чтение, но изменения будут сложнее и тяжелее.
alex_nsk, Ну так все запросы будут идти по индексам, даже +30% не так много для быстрых запросов. Десяток составных индексов это более плохое решение. К тому же есть еще запрос "общее число доступных значений", так что здесь однозначно все надо раскладывать по полочкам.