sashka_, я такой вариант не пробовал. Вот тот вариант что привел вполне удовлетворяет моим требованиям.
и потом, конкретно в данном случае каунт делать не обязательно, т.к число кеев в БД - это внутренняя константа, которая висит в скрипте, осталось лишь выяснить что отработает быстрее - ORDER BY RAND или LIMIT с двумя границами, очень вероятно что на бд до 100к записей разницу мы не ощутим. Точнее чтобы сказать - надо поводить тестирования.
На момент написание релиза меня реально ни одного тестового дора в бан не ушло, потом я их не проверял, а вот ап 26го сильно поменял карты, теперь я насчет индекса Я так утврждать уже не могу, так как перекосило очень много доров, но экземпляры залезшие в Я и пережившие 1 ап уже есть. Доры показываю по запросу при предпрокупочной консультации в аське. Аську в ЛС скинул.---------- Добавлено 15.11.2013 в 01:22 ----------
Да, дор с тектовой БД.
В 4й та же эмуляция CMS которая реализвана в тройке, но уже в динамическом режиме, плюс благодаря особенностям динамики - возможноа смена настроек налету.
По ситсемным требованиям - на данный момент система тестировалась только на Xeon 3210 Quad Core / 2GB . Потому минималку по системным требования я бы назвал 2ядра / 2Гб оперативной памяти.
Владельцам 3ки - 4я будет предоставлена бесплатно. По владельцам предыдущей первой версии еще принимается решение - вероятнее всего это будет ап с доплатой разницы в цене - пока думаю.
Тормозов до 100к я не наблюдал но делаю по 10-20к.
Запарился, это я так массив рандомный выбираю, да ))
sidorka, рандом - это такой запрос
sqlite_query($db, "SELECT * FROM keywords ORDER BY RANDOM() LIMIT {$limit};");
лимитом регулируешь ширину выборки, вот посредством ширины я, насколько помню, и оптимизировал этот запрос.
Заморачиваться смысл имеет, так как с неотрегулированным лимитом тупить будет. Но с сильно низким лимитом - будет падать качество рандома. БД по 10-20к кеев делаю.
по чтению разницы я не заметил, но вот по скорости записи по моим наблюдения скулайт протарчивает мускулу. Очень сказывается количество записей в бд. До 100к я бы сказал они ведут себя практически аналогиным образом.
Лайт на запись более тормознут чем на чтение, особенно сложные запросы. Имхо лучше не заморачиваться с синхронизацией и разделением чтения записи а делать просто отдельную бд под каждый дор, и между этими бд уже вести логику учитывающей статистики, чтобы в отделньой бд отображались статусы и сводная кратина по всем дорам. До 100к скулайт ведет себя нормально.
sidorka, кстати да, если домешивать своих тэгов то то во-первых сразу упрощает алго парсинга текста, второй момент - по такой технологии можно делать вообще из книжек.
Dos3, посмотрел - нормальный текст, но я сейчас отказался от простыней полностью чищеных от тегов - есть подозрение что полностью отбеленный от тегов текст - палево.
Bramin, дружищ, сабж платен))
Дак, че молчишь, спроси в аську, я тебе подскажу по вопросам.---------- Добавлено 14.11.2013 в 16:01 ----------Dos3, ок погляжу ))
Dos3, почему флуд, наборот полезные мессадж. Я мб такой алго в дорген добавлю, если ты не против канеш )