Хороший броузер. У меня основной броузер Opera 9 (WebTV) - это намного хуже.
Дятлы хреновы. Не могли повесить форму сбора денег. Первым проплачу.
В начале было Слово. И Слово...
Слово обрезать по-любому некошерно. Слово - не член.
у себя сделал что-то типа фильтра.
Если:
"Слово
Слово
Слово"
автор идет лесом + сообщение модератору.
Но если укладывается в минимальный стихотворный размер, то урезается до четырех строк.
С таким маразмом я не сталкивался. К счастью.
Проблемы были в IE6 и Opera9- . Последнее для меня до сих пор актуально. Поэтому я бы не задумываясь сделал через js. Это 100%-гарантия что не будет сюрпризов.
А как правильно решать я не знаю. Честно. Но чисто логически, если уж добавлять блочные свойства то нужно добавлять всем элементам таблицы. Иначе получается совсем уж х.з. что.
Не факт. Код зашит в какой-нибудь компонент супер-пупер-фреймворка, а его трогать верстальщик не имеет прав/возможности/квалификации. Не сталкивались?
А вот то что в старых броузерах это вызвало траблы - точно. И я не знаю точно, было ли это багом или следствием неопределенности стандарта.
Всюду? Или только в вашем любимом броузере? А через год?
Самая длинная дискуссия на эту тему здесь. Те кто ратует за такой способ (они в меньшинстве), как правило работают или с Oracle или c MS SQL. И там и там всегда был механизм, оптимизирующий хранение BLOB. В отличие от MySQL, в котором он в оригинале не присутствует.
Везде пишут о тонкостях, при которых удается получить выигрыш и отсылки на существующие бенчмарки. Как правило он получается при хранении большого числа мелких файлов.
Мне как раз сложно представить проект в котоором приходится заморачиваться хранением большого числа картинок и при этом он размещается на пятикопеечном шареде.
Вы еще напишите без доступа к SSH.
1. Я не пропагандирую этот метод, и сам делать не буду - в собственных проектах таких проблем никогда не возникало. нет таких задач. Но отмечаю что он существует и Яндекс знает 2 миллиона страниц в которых эта тема обсуждается.
2. Речь насколько я понимаю идет о чем-то очень большом. Иначе не было бы смысла заморачиваться этим вопросом.
И что проще? Любая БД на гиг забэкапиться быстрее чем большое количество мелких файлов на тот же самый гиг. И точно так же быстрее развернется.
Сам не реализовывал (я вообще не программист), но в двух конторах которых работал это практиковалось. Назвать этих программистов лохами не смогу. Реально большие высоконагруженные проекты (400.000 хитов)
UPD ПО поводу инкрементального архива. В обоих случаях были MS-разработчики. А там насколько я знаю можно делать бэкап частичный. Всю БД гнать в бэкап не надо.
