Рост - 12-5-2004 у 14:26
Є така собі проблемка.
Аналітичний сайт. Статті. Глосарій. Є потреба виділяти слова з глосарію в статтях
у вигляді посилань на той же глосарій. Тобто, виводиться стаття, є слово, що
міститься в глосарію - воно перетворюється на посилання.
Так от, щодо реалізації. Добре, якщо глосарій маленький. Тоді при виводі скрипт
прокрутить саттю по всіх ключових словах, автоматично виділивши потрібні,
вірніше, перетворивши їх на посилання. А якщо глосарій розростеться?
Прокручувати заміну слів статті одноразово, перед публікуванням - тоді не
враховується поповнення глосарію.
Може хтось підкаже якийсь вихід, що і враховуватиме поповнення глосарію, і не
з`їдатиме ресурси сервера та не гальмуватиме вивід статей?
Олексій Мачехін - 12-5-2004 у 14:58
Як на мене - або "переформатування" всіх статей після поповнення глосарію
(скажімо, в момент найменьшого завантаження серверу серед ночі раз на добу за
умови поновлення, або за кожного поновлення, власне, порте треба уважно
поставитись аби слова не підмінялись при кожному переформатуванні вдруге і
втретє), або оптимізація функції підстановки і робити на льоту.
marco - 13-5-2004 у 12:41
Це залежить від інтенсивності наповнення словника та інтенсивності відвідування
сайту.
У будь-якому випадку робити заміну "на льоту" нераціонально. Я так розумію що
з часом і словник буде розширюватись і кількість статей збільшуватись. Тому краще
видавати закешовані сторінки з згенерованими лінками.
Якщо словник поповнюється часто (декілька- десятки слів за день) - то тоді краще це
робити перегенерацію статтей раз на добу вночі запускаючи з кронтабу.
Якщо не часто (декілька-десятки за тиждень) то тоді можна при потребі вручну
очищати кеш і запускати перегенерацію.
Тарас Сокальський - 23-6-2004 у 19:30
Якщо тема ще актуальна, впхаю своїх 5 копійок.
1. Статті із згенерованими лінками тримаємо в кешах.
2. Ведемо хроніку поповнення/вилучення слів в глосарії.
Кожну подію нумеруємо. Номер = версія глосарію.
3. Тримаємо базу, в якій для кожної статті з кешу
зазначується версія глосарію, під яку вона (стаття)
проіндексована.
4. Оновлення лінків здійснюємо після кожної події п.2
в режимі найнижчого пріорітету. При цьому не перепорпуємо
весь глосарій, а лише враховуємо ті події, які відбулися
після попереднього оновлення, тобто з номерами, більшими
від вказаних в базі(п.3). Після чого, певна річ, коректуємо
версії статей.
5. При зверненнях до закешованих статей звіряємо версії
статті і глосарію, при невідповідності на льоту в алярмовому
порядку доставлюємо лінки на нові слова (не забувши результат
покласти в кеш і підправити версію статті).
6. І, звичайно, додаючи нову статтю, перетрясаємо весь
глосарій і записуємо в кеш статтю із згенерованими лінками.
Хоча цього робити не конче, можна вписати в кеш статтю без
лінків і з нульовою версією глосарію, тоді лінки вставляться
автоматично при першому зверненні до статті(див п.5) або при
наступному поповненні глосарію. Але в першому випадку буде
затримка.
7. Про всяк випадок передбачити перед вставлянням лінку в
статтю перевірку, чи він там вже не стоїть (це може бути в
разі збою при корекції версії статті). Найпростіше перескакувати
слова, які вже є лінками.
Таке от моє чайницьке уявлення, як мінімізувати завантаження
сервера і прискорити обробку запитів.
О, а як бути з розпізнаванням різних відмінкових форм
слів? Певно, треба до кожної статті глосарію додавати
парадигму слова і вишукувати в тексті всі варіанти. Тобто,
роботи при генеруванні лінків додається, і питання оптимізації
постає в усій красі.