Из плюсов - локальная (!) вики с тегами (!), простым и удобным синтаксисом (после неё вырвиглазный синтаксис медиавики мне кажется угробищным). К старой тиддливики написано множество плагинов на любой вкус.
Из минусов - честно говоря, мне не хватает визивига. Плагин wikibar есть, но он не очень то удобен. Я видел рецепты по прикручиванию к TW CKEditor или TinyMCE, но это костыли - потому что эти редакторы на выходе генерят html-код, а не tiddlywiki-разметку. А перепиливать еще и TinyMCE под это...
Из практического использования: каталог CD/DVD я привел, вики для НРИ-сеттингов тоже.
Еще я хранил в ней everyday-заметки и копипасту из интернета (встретил статью, сохранил к себе) - но не покажу, там много приватной инфы ;)
Дневник вёл несколько лет.
Мой давний проект - запилить на базе TiddlyWiki концепции TODO-list и хранилку паролей/логинов и вообще регистрационных данных, но планам уже года три, а воз и ныне там. Всё как-то не заняться.
Александр Зонов: сейчас в ходу новая, модная версия tiddlywiki, но мне у неё совершенно не нравится интерфейс и перепиливать новую версию под свои нужды мне лень. Я привык к старой версии - по ссылке моя сборка с кучей плагинов, хинтов, справки и так далее.
Vit: мне это напоминает мою "аррис-метрику", которую я писал 6 лет назад и даже написал :) Пример абсолютно бесполезного и неоптимизированного хранения данных.
Итак, поехали:
1. Подумайте, как вы можете идентифицировать посетителя однозначно в пределах одного посещения сайта?
2. Ответьте на вопрос: может ли пользователь в процессе посещения сайта во время перехода между страницами СМЕНИТЬ: Страну, город, браузер или OS?
Объяснять, что нам это дает? :)
Далее,
3. зачем хранить страну и город в явном текстовом представлении?
4. может быть вам стоит использовать какую-нибудь яндекс-метрику?
Пока что я вижу только бессмысленный сбор и хранение избыточных данных.
Артем Каретников: ага. Я догадываюсь, в каком проекте имела место такая ситуация ;)
> По крайней мере, пока записей не миллионы
Мы ничего не знаем о проекте, только какие-то фантастические предположения о миллиардах записей, которые надо хранить вечно и каждая запись занимает чуть ли не по килобайту. Это даже не преждевременная оптимизация, это я не знаю как назвать...
Хм, интересно, а как хранят данные разработчики яндекс-метрики?
Vit: ну если бы я решал такую задачу (а я не знаток современных высоконагруженных технологий), я бы в отдельной БД для логов плодил таблицы вида eventlog_YYYY_MM_DD :)
Потом я бы задумался, надо ли мне сравнивать статистику посещений за январь и август и не будет ли достаточно стастистики за последний месяц для ОЦЕНКИ нужных показателей. (не исключено, что можно написать алгоритмы сопоставления кэшированной статистики (посчитанной для прошедших месяцев) и статистики за последний месяц (сравнительно небольшой таблицы).
Ну собственно и вот. Конечно от решения попахивает говнокодом, но я не специалист по highload.
Но опять же - сколько у вас сейчас собирается событий за сутки?
Александр Таратин: ох уж эта страсть к "человекопонятным адресам"! Скажите, а почему же тогда ютуб, фейсбук и гугл обходятся без них? :)
Экономят на разборе роутинга на миллиардах запросов?
P.S. Закачик одного из моих сайтов _потребовал_, чтобы адреса были вида ?fetch=book&with=author&id=100. Нравится ему так. А сказки о том, что такие адреса "плохо индексируются" так и остались сказками. Все у нас отлично индексируется.
