|
|
|
| Как организовано хранение сообщений участников которые общаются в социальных сетях?
Вот например Дина и Саша общаются между собой, пишут друг другу сообщения, где лучше хранить сообщения которые они пишут друг другу? Ведь если пополнять таблицу БД это не целесообразно.
Создавать отдельные файлы для тех кто начинает общение, а потом по окончании удалять тоже смешно, таких файлов будет создаваться тысячи или сотни тысяч в случае если много человек переписывается между собой.
А таких пользователей которые друг другу пишут тоже много. Как вообще все организовано в соц. сетях? | |
|
|
|
|
|
|
|
для: asked86
(11.04.2010 в 16:32)
| | >Как организовано хранение сообщений участников которые общаются в социальных сетях?
>
>Вот например Дина и Саша общаются между собой, пишут друг другу сообщения, где лучше хранить сообщения которые они пишут друг другу? Ведь если пополнять таблицу БД это не целесообразно.
После последней фразы должна следовать аргументация.
Иначе неясно, с поциций чьей целесообразности Вы ожидаете ответ. | |
|
|
|
|
|
|
|
для: Trianon
(11.04.2010 в 17:18)
| | -> Создавать отдельные файлы для тех кто начинает общение/ Аргументация, будет сильно много файлов очень тяжело будет работать устройству хранения.
А как тогда организовать хранение их сообщений в БД просто пополнять что ли? | |
|
|
|
|
|
|
|
для: asked86
(11.04.2010 в 17:38)
| | Почему нужно создавать отдельные файлы?
Почему не хранить в одном?
Это если не применять БД.
Почему не применить БД?
Если применить, то почему
>Ведь если пополнять таблицу БД это не целесообразно.
?
Почему Вы полагаете, что очень много файлов тяжело устройству хранения? | |
|
|
|
|
|
|
|
для: Trianon
(11.04.2010 в 18:00)
| | Ну если около 100 тыс человек одновреименно что - то записываать будут...
Мне кажется целесообразнее субд применять ..
Хотя не знаю, вы можете подсказать как лучше сделать? | |
|
|
|
|
|
|
|
для: asked86
(11.04.2010 в 20:37)
| | 100 000 человек одновременно ничего записывать не будут.
100 000 человек одновременно чисто теоретически могли бы отправлять запрос на запись, но СУБД обрабатывались бы эти запросы все равно последовательно.
Чисто теоретически - потому что у Вас не будет такой посещаемости, а когда (и если) будет на практике, тогда Вы будете уметь решать такие проблемы и будете обладать процессорными мощностями, достаточными для того, чтобы Вас эта проблема волновала слабо. | |
|
|
|