[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Подскажите, как лучше хранить ресурсы юзеров?
GET
Здравствуйте, помогите, советом как лучше спроектировать хранение персональной инфы юзеров.

Инфа о зарегистрированном юзере (пароль, электронка и т.д.) само-собой хранится в таблице users БД (строка под номер 16 , например), в этой таблице также ссылки на файлы (фото, например) юзера, сами они (фото) лежат в каталоге юзер, напрмер "STORM".

"STORM" размещает некоторыю информацию в таблицах (темах), точнее в строках, каждая строка соответсвено имеет уникальный номер для этой таблицы.

Т.е. для поиска записи "STORM"а нужно знать:
1. Название таблицы
2. Номер строки

У одного пользователя их может быть много т.е.
Таблица RED строка №266
Таблица RED строка №23
Таблица BLACK строка № 763

и т.д.

Можно создать таблицу типа:
id | tab | number |

, где id будет совпадать с id юзера а таблице USERS, если номер = 16, то

16 | RED | 266
155 |BLACk | 45
16 |BLACK | 46

...и т.д.

смысл в том, что для нескольких тысяч юзеров это таблица станет гигантской.

Выхода вижу либо сделать 26 таблиц для юзеров (26 букв в латинице, первая буква ника юзера) чтоб снять нагрузку и тогда STORM и SOFA будут оставлять инфу в одной таблице, а BSTORM в другой.

Либо (что приемлемее) чтоб инфа о оставленных записях хранилась в одном месте и даже файле вместе с фото юзера в его каталоге. Что то типа scv файла что-ли.
Кто как решает этот вопрос?



Спустя 11 минут, 18 секунд (1.05.2011 - 10:27) quickxyan написал(а):
впринципе БД для того и есть, чтобы в них пихали очень много инфы)
я вот склоняюсь к БД, хотя наверное лучше всего почитать где-то про преимущества и недостатки БД и файлов. думаю сам тогда решишь, что лучше.

Спустя 3 минуты, 47 секунд (1.05.2011 - 10:31) GET написал(а):
quickxyan
Да вот уже как бы начитался smile.gif и не могу решиться т.к. это базовое место и его потом не переделать, после запуска сайта я имею ввиду.


Спустя 3 минуты, 29 секунд (1.05.2011 - 10:34) quickxyan написал(а):
ну я склоняюсь все же к базам, вот только спроектировать надо очень скурпулезно, чтобы небыло избыточного дублирования данных и тп. и тд.

Спустя 5 минут, 19 секунд (1.05.2011 - 10:40) GET написал(а):
quickxyan

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

Вариант с файлами: мы зайдем в каталог STORM и вытащим небольшое(!) содержимое файла storm.txt ту же самую инфу, т.е. поиска по тысячам строк не будет.

Спустя 8 минут, 19 секунд (1.05.2011 - 10:48) quickxyan написал(а):
ну тогда делай на файлах)

Спустя 7 минут, 23 секунды (1.05.2011 - 10:55) GET написал(а):
Но для файлов придется писать кучу проверок и перемещений метки внутри файла, а также удаление отдельных записей внутри файла может стать трудоемким.


Спустя 2 дня, 1 час, 1 минута, 36 секунд (3.05.2011 - 11:57) GET написал(а):
И все таки не теряю надежды услышать вразумительный ответ.

Спустя 1 час, 48 минут, 29 секунд (3.05.2011 - 13:45) Arni написал(а):
Послушайте, не порите горячки с этими файлами. Там вас ждет больше бед чем счастья. Начиная от проверки а не пишется ли часом что-то в этот файл и заканчивая тем что частые обращения к диску это хуже чем запросы в базу.

Цитата
нам придется написать запрос, которые среди тысяч записей найдет десятки соответствующих номеру STORMA


Вы что действительно верите в то что каждый раз сервер базы данных роется в этой горе строк? smile.gif Нет, далеко не так. Он кеширует все что только возможно. И если в след за запросом пошел точно такой-же, и до этого не поступало запросов на предмет вставки или обновления, он вам выдаст кеш. Я не заню какого масштаба ваш проект, но нынешние сервера обалденно крутят миллионы строк.

Спустя 13 минут, 36 секунд (3.05.2011 - 13:59) GET написал(а):
Arni
спасибо...smile.gif


_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.