Здравствуйте. Пишем небольшую узкоспециализированную социальную сеть. При написании обмена сообщениями возник вопрос и ступор. Дело в том, что история сообщений будет храниться в базе, а какая именно структура будет более быстро работать - не ясно. Есть 2 варианта: 1. Записываем в базу со структурой: Username(одна строка, содержащая имя пользователя), Message(содержит записи, разделенные символом, к примеру, запятой: "дата":"получатель":"сообщение", "дата2":"получатель2":"сообщение2",...и т.д.), То есть несколько логов чата в одной строчке, ограничим её количество символов, например до 10 000 и потом парсить её по разделителю, выстраивая историю. 2. Для каждой новой записи лога чата создаём новую строку, то есть не нагромождаем всё в одну кучу. Например: Username, ToUsername(получатель), Message, Date - тут заканчивается и след запись пошла: Username2, ToUsername2(получатель2), Message2, Date2 ...и т.д. Сам лично склоняюсь ко второму варианту. Руководитель хочет работать с первым, аргументируя тем, что записей в таблице будет меньше и работать будет быстрее. Мне лично на деле не понятно, какой вариант должен работать лучше и скоростнее, но на мой взгляд - парсинг делает дополнительную нагрузку. Хотя, наверное, лучше виднее тем, кто знает досконально структуру и принцип обработки MySQL, поэтому и вопрос - как будет быстрее: обработка меньшего количества строк в которых содержится множество записей и их парсинг, либо обработка множества строк, но получается уже без парсинга?
Re: Как лучше с точки зрения работоспособности и оптимизации Регуляркой небось? А вообще, оба принципа очень легко собрать в тестовый прототип. Реализуйте оба, много времени не займет. Потом засрите оба. Потом начните оба дергать и замеряйте время и расход памяти. И откроется истина, что быстрее в вашей ситуации и что экономичнее. И, потом, не забудьте о том, что будет более удобно править, когда начнутся изменения в системе? А они начнутся. Что гибче, а что деревяннее? Это уже надо будет сесть, подумать отдельно.
Re: Как лучше с точки зрения работоспособности и оптимизации Конечно регуляркой. Ну к тестовому прототипу и приходим. Малоли кто изначально сможет посоветовать.
Re: Как лучше с точки зрения работоспособности и оптимизации Конечно второй вариант - меньше головной боли. И Ваш шеф неправ, - скоростя будут одинаковые (почти) для вашей задачи. До ~1000 зап в сек вам хватит одного сервера mySQL, а дальше или кеш или кластер серверов.
Re: Как лучше с точки зрения работоспособности и оптимизации Думаю за 1000 зап/сек мы врядли выйдем по роду деятельности сети. Нужно просто узнать какой именно способ теоретически работает лучше при высоких нагрузках. Постоянный парсинг, или много записей...
Re: Как лучше с точки зрения работоспособности и оптимизации Ну распарсите 1000 раз документ в 10000 символов, посчитайте время. И сделайте из базы 1000 выборок по 10000 строк. Другое дело, что в случае со строками у вас каждая запись - это сущность. У нее есть ID, ее можно удалить, можно отредактировать, можно найти по поиску, можно отослать разным пользователям в комнате чата. А теперь вот то же самое представьте с простыней под парсер.
Re: Как лучше с точки зрения работоспособности и оптимизации Я так понял речь не идет о втором фейсбуке, пользователей не миллионы. Даже если предположить, что ваш парсинг дает какие-то преимущества по скорости, это просто лишние сложности и ограничения. Если начнете упираться по скорости, что врядли, лучше смотрите на nonSQL вроде redis. Кстати для redis есть готовый пример "твиттера".
Re: Как лучше с точки зрения работоспособности и оптимизации Тогда не нагружайте себе мозг и делайте по классике. Я выше написал, что примерно одинаково. В первом случае чуть больше будет нагружен PHP, во втором - больше mySQL. Для вашей задачи разница будет несущественная, поэтому можете делать как вам удобно, - я рекомендую классику. О конкретных цифрах не готов говорить, но подобный выбор делал в прошлом - никаких принципиальных преимуществ первого перед вторым мы не нашли тогда.