Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Самый сложный выбор - когда варианты так похожи... / 8 сообщений из 8, страница 1 из 1
25.02.2005, 18:25
    #32934407
webxtor
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Самый сложный выбор - когда варианты так похожи...
Всем привет!

Немного вступления.
Я делаю очень большой проект. База данных будет занимать место около гига. Поэтому все тонкости оптимизации структуры БД и запросов к ней, тут крайне важна! Использую БД MySQL. Мне кажется, этот проект использует абсолютно все технологии и сталкивается со всеми проблемами хранения данных в БД в вебе, поэтому вам будет очень важно прочитать этот топик и попробовать мне помочь :)

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

Категорий 1,500 штук. Уже организовал их по приниципу вложенных множеств. Все работает классно!

Изучил теорию индексации - скорость работы возросла в несколько раз!

А теперь самое сложное.. то, когда выбор приходится делать из очень похожих друг на друга вариантов.

Итак, суть проблемы.

Нужно хранить 4 типа данных:
1. контактная иформация, логин и пароль компаний
2. профиль компании (для каждого пользователя может быть только один профиль компании)
3. продукты компании
4. торговые предложения компании

Все вопросы я выделю жирным шрифтом . Просьба в ответе написать свое видение организации БД, учитывая, что компаний будут сотни тысяч и соотвественная посещаяемость.

Как хранить контактную информацию (имя, фамилия, телефон, сайт.. всего 10 полей о компаниях:
-в одной таблице, а профиль компании (название, год создания, штат.. всего 20 полей) - в другой? Или все же сделать одну таблицу на 30+ полей?

Хочется разбить эту таблицу на 2, так как на всех страничках касательно этой компании (на всех ее продуктах и торговых предложениях и конечно на ее профиле) внизу будет отображаться контактная информация этой компании.

А может сделать вообще 3 таблицы? В одной храним логин и пароль и время последнего логина, время регестрации и тд, в другой 10 полей контактов а в третей 20 полей профиля компании?

И еще, если скажем появится на сайте возможность создания золотых аккаунтов, для которых количество полей профиля будет увеличино. И обычные пользователи смогут вносить только 10 полей профиля своей компании, а золотые все 20, то в этом случае, как следует быть с таблицами? Сделать 2 таблицы - базовые профили и золотые профили? Или сделать одну таблицу, где у простых пользователей будет всегда 10 пустых полей?
Или сделать одну таблицу на 10 полей, а другую на 20, и при улучшения статуса до золотого, копировать данные данного пользователя в новую таблицу, а из старой удалять?

И еще очень важный момент. Каждое создание профиля/обновление должно проходить через модератора. То есть даже если уже все внесето и посетители сайта просматривают инфу, а владелец компании изменил профиль, то новый профиль должен появится у модератора, а старый все так же висеть на сайте.
Как тут быть? Сделать временную таблицу, из которой постоянно удалять записи при одобрении модератором и перезаписывать информацию в оригинальную? Или в оригинальной таблице сделать еще столько же полей, приписав к названию скажем _temp, но тогда таблица будет иметь 40 полей.. нехорошо вроде как!

Это же касается и продуктов и с тороговыми предложениями. Как там быть с модераторством? Делать временные таблицы или очень большие или сделать пару дополнительных полей, по которым будет ясно, где оригинал, а где ждущая модерирования запись?

И вообще, что лучше, постоянно удалять и записывать или только обновлять (оставлять поля пустыми, кроме ID и company_id)?

Всем, всем всем приооогромной спасибо!!
...
Рейтинг: 0 / 0
25.02.2005, 18:40
    #32934437
Самый сложный выбор - когда варианты так похожи...
Вам рановато проектировать такие базы данных.
...
Рейтинг: 0 / 0
25.02.2005, 18:45
    #32934444
Dogen
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Самый сложный выбор - когда варианты так похожи...
Тут прикол не в базе, а в том, раскрутится ли оно

Если будет сделано в качестве учебного проекта, то навряд ли. Тут ведь не в бэкэнде дело, дело в юзабилити :]

"пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги"
...
Рейтинг: 0 / 0
25.02.2005, 21:03
    #32934580
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Самый сложный выбор - когда варианты так похожи...
> Тут ведь не в бэкэнде дело, дело в юзабилити :]

Одно логично вытекает из другого.
...
Рейтинг: 0 / 0
25.02.2005, 23:45
    #32934655
webxtor
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Самый сложный выбор - когда варианты так похожи...
Кто-нибуь может ответить предметно?

Проект никакой не тестовый. Дизайн уже готов и юзер-энд продуман. Это не важно. Важно продумать как сообственно спроектировать БД, чтобы все работало гладко.

На счет сотен тысяч компаний - они будут сграблены с других сайтов. Пару десятков тысяч я уже сграбил. Так что сайт будет стартовать сразу с большой базой данных.

ОЧЕНЬ хочется услышать ваши конкретные пожелания касательно структуры таблиц связанные с модерацией и более частым извлечением одних полей таблицы, чем других (контактные данные чаще отображаются чем профиль компании, хотя как бы и то и то хранится в одной таблице).

Скрипт уже готов, но нету никакой модерации и разбиения на несколько таблиц. Но прежде чем переделывать, хотел услышать мнение опытных людей.

PLEASE HELP ME IF YOU CAN!
...
Рейтинг: 0 / 0
26.02.2005, 00:23
    #32934670
Самый сложный выбор - когда варианты так похожи...
> PLEASE HELP ME IF YOU CAN!

$40/час.
...
Рейтинг: 0 / 0
26.02.2005, 01:24
    #32934691
webxtor
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Самый сложный выбор - когда варианты так похожи...
Вот сократил вопросы до минимума:

1. Если выборка по одним полям таблицы, делается чаще, чем по другим, стоит ли делать отдельную таблицу для тех полей, которые берутся реже? В данном случае, или если хотите, например, чаще берутся контактные данные пользователя, а реже - профиль его компании, хотя концептуально это одной группы данные.

2. Если требуется организовать модерируемость некоторых таблиц, с учетом того, что уже отмодерированные данные должны быть неизменными до момента очередного одобрения модератором, то стоит ли создавать временную таблицу для модерируемых данных с целью снизить нагрузку на основную таблицу из которой постоянно делается выборка?

2.1. Если создавать таблицу сугубо для временных (ожидающих модерирования) данных, то лучше чтобы записи удалялись/записывались или обновлялись (на пустые значения при одобрении и на желаемые изменения, ожидающие модерации)?
...
Рейтинг: 0 / 0
26.02.2005, 12:44
    #32934827
webxtor
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Самый сложный выбор - когда варианты так похожи...
Сорри.. можете не читать.. тут много воды! Создал новый, максимально конкретный топик!
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Самый сложный выбор - когда варианты так похожи... / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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