Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Самый сложный выбор - когда варианты так похожи...
|
|||
|---|---|---|---|
|
#18+
Всем привет! Немного вступления. Я делаю очень большой проект. База данных будет занимать место около гига. Поэтому все тонкости оптимизации структуры БД и запросов к ней, тут крайне важна! Использую БД 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)? Всем, всем всем приооогромной спасибо!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2005, 18:25 |
|
||
|
Самый сложный выбор - когда варианты так похожи...
|
|||
|---|---|---|---|
|
#18+
Вам рановато проектировать такие базы данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2005, 18:40 |
|
||
|
Самый сложный выбор - когда варианты так похожи...
|
|||
|---|---|---|---|
|
#18+
Тут прикол не в базе, а в том, раскрутится ли оно Если будет сделано в качестве учебного проекта, то навряд ли. Тут ведь не в бэкэнде дело, дело в юзабилити :] "пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2005, 18:45 |
|
||
|
Самый сложный выбор - когда варианты так похожи...
|
|||
|---|---|---|---|
|
#18+
> Тут ведь не в бэкэнде дело, дело в юзабилити :] Одно логично вытекает из другого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2005, 21:03 |
|
||
|
Самый сложный выбор - когда варианты так похожи...
|
|||
|---|---|---|---|
|
#18+
Кто-нибуь может ответить предметно? Проект никакой не тестовый. Дизайн уже готов и юзер-энд продуман. Это не важно. Важно продумать как сообственно спроектировать БД, чтобы все работало гладко. На счет сотен тысяч компаний - они будут сграблены с других сайтов. Пару десятков тысяч я уже сграбил. Так что сайт будет стартовать сразу с большой базой данных. ОЧЕНЬ хочется услышать ваши конкретные пожелания касательно структуры таблиц связанные с модерацией и более частым извлечением одних полей таблицы, чем других (контактные данные чаще отображаются чем профиль компании, хотя как бы и то и то хранится в одной таблице). Скрипт уже готов, но нету никакой модерации и разбиения на несколько таблиц. Но прежде чем переделывать, хотел услышать мнение опытных людей. PLEASE HELP ME IF YOU CAN! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2005, 23:45 |
|
||
|
Самый сложный выбор - когда варианты так похожи...
|
|||
|---|---|---|---|
|
#18+
> PLEASE HELP ME IF YOU CAN! $40/час. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2005, 00:23 |
|
||
|
Самый сложный выбор - когда варианты так похожи...
|
|||
|---|---|---|---|
|
#18+
Вот сократил вопросы до минимума: 1. Если выборка по одним полям таблицы, делается чаще, чем по другим, стоит ли делать отдельную таблицу для тех полей, которые берутся реже? В данном случае, или если хотите, например, чаще берутся контактные данные пользователя, а реже - профиль его компании, хотя концептуально это одной группы данные. 2. Если требуется организовать модерируемость некоторых таблиц, с учетом того, что уже отмодерированные данные должны быть неизменными до момента очередного одобрения модератором, то стоит ли создавать временную таблицу для модерируемых данных с целью снизить нагрузку на основную таблицу из которой постоянно делается выборка? 2.1. Если создавать таблицу сугубо для временных (ожидающих модерирования) данных, то лучше чтобы записи удалялись/записывались или обновлялись (на пустые значения при одобрении и на желаемые изменения, ожидающие модерации)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2005, 01:24 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32934655&tid=1546020]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
51ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 272ms |
| total: | 411ms |

| 0 / 0 |
