V-Vilkin: Просто заказчик не хочет руками это делать,
Автоматически посчитать суммы (в интернет-магазине/в бухгалтерской программе/в Excel - неважно).. за прошедший период, оценить/проверить правильность и перевести ручками - так надёжнее..
Автоматизация в принципе возможна, если банк одобряет..
Ну, я и говорю (точнее, не совсем я - "официальные источники"), что это не совсем соответствует действительности.
tish88: И? Получается, что Макхосту всего 3 года?)) Всем известно, что компания старая. Видимо они ООО просто только в 2010 году зарегистрировали.
tish88, ситуация несколько иная. Если действительно интересно - яндекс/гугл в помощь.
tish88: Однако замечу, что никто из них ведь не сказал, мол это другой Макхост, другая компания. Потому как в действительности это та же компания и есть.
Я не знаю, какой смысл Вы пытаетесь вложить в слово "компания". Это другое ООО.
Есть репутация. И есть заявления вроде:
Игорь Белов: Всем, кто обращался по поводу возврата средств — мы вернули (о чем здесь отписывали те, кому вернули).
И есть те, чьи вопросы (даже в этой теме) остались без ответа.. (а ещё есть те, кто давно уже забил и пошёл дальше)
ware: Может он решил подождать 3 года, когда все обязательства по деньгам станут ничтожными. Кстати, в каком году с ними это всё произошло?
"это" произошло с другим "ООО".. Т.е. у "новой" (текущей) компании нет "тех" обязательств.
Ayavryk: Самая длинная дискуссия на эту тему здесь.
Ayavryk, спасибо.. видел и это..
Цитата из поста (дабы не разрывать - приведу целиком):
Больше о проблемах, возникающих при хранении файлов отдельно от БД можно почитать в презентации SQL Antipatterns, раздел Phantom Files, страница 60. Кстати, автор презентации предлагает решение — хранить файлы прямо в БД, в поле типа BLOB. Правда следует замечание, что это должно быть взвешенное решение в каждом конкретном случае. Ведь при таком способе хранения файлов вебсервер должен при каждом запросе вызывать некий скрипт, который будет извлекать файл из БД и отдавать пользователю, что неминуемо отрицательно скажется на производительности.
Антипаттерном по мнению автора презентации являются "фантомные" файлы, возникающие при рассинхроне FS и БД при удалении, или транзакции (файл уже сохранён, а транзакция откатывается, или наоборот).
ИМХО, "проблема" решается простым сборщиком мусора (пишется на коленке), правильным порядком сохранения (файл, база) и, при необходимости, lock-ом при обновлении.
You’re right. Storing images in MySQL is in most cases not a good idea being it MyISAM or Innodb storage engine. I’m not sure how this post made you feel it is being recommended.
Из минусов такого подхода:
- в оперативке вместо "полезных" данных (индексы, временные таблицы, кэш) висят файлы (если нет - опять же читается с диска (БД), а затем - отдаётся веб-серверу. Вместо прямого диск->веб-сервер).. При этом в случае хранения в файлах часто используемые кэшируются на уровне FS. При необходимости можно tmpfs подмонтировать
- нужно извращаться, чтобы отдать файл браузеру (тут речь о "стандартном" L(A|E)MP, а не про встроенный в СУБД web-сервер или плюшки вроде FILESTREAM) - php, коннект к базе, получение файла, его отдача (vs отдача напрямую Nginx-ом из FS)
В общем, метод имеет право на жизнь, наверняка успешно применяется (в определённых условиях), но с учётом:
должно быть взвешенное решение
и
revered: Но есть маленькая проблема, сайт довольно крупный, планируеться большая посещаемости, и когда аватарок будет допустим 100.000, получаеться будет 400 папок. Что тоже уже много.
я бы не рекомендовал ТС-у использовать этот вариант.
в данный момент сменил хостинг и есть проблемы. Как можно по другому прописать его в тело:
А проблемы-то какие? PHP на хостинге установлен?
Техподдержка нового хостинга на этот же вопрос что отвечает?
прописывал AddHandler
С точками (.htm .html) тоже не работает?
Ещё так можно..
как создать сайт гостиницы с возможностью автоматически бронировать номера в отелях на Joomla?
так гостиница одна, или отелей много?
Просто заказчик не хочет руками это делать,
Автоматически посчитать суммы (в интернет-магазине/в бухгалтерской программе/в Excel - неважно).. за прошедший период, оценить/проверить правильность и перевести ручками - так надёжнее..
Автоматизация в принципе возможна, если банк одобряет..
Если нет - тоже возможна, но сложнее.
http://forum.ixbt.com/topic.cgi?id=57:697
Тут одними правилами не обойдёшься.. Нужно, чтоб движок по новым адресам нужные страницы открывал.
RewriteCond %{QUERY_STRING} =id=14RewriteRule ^content/index.php$ http://www.site.com/new-page? [R=301,L]
WTF? Форум русскоязычный.. WHT не хватает?
Может не там смотрю, но в строке домены стоит рнр,
тогда в .htaccess смотреть всё, что касается php
С того же http://mchost.ru/about/ и с заглавия данной темы.
Ну, я и говорю (точнее, не совсем я - "официальные источники"), что это не совсем соответствует действительности.
И? Получается, что Макхосту всего 3 года?)) Всем известно, что компания старая. Видимо они ООО просто только в 2010 году зарегистрировали.
tish88, ситуация несколько иная. Если действительно интересно - яндекс/гугл в помощь.
Однако замечу, что никто из них ведь не сказал, мол это другой Макхост, другая компания. Потому как в действительности это та же компания и есть.
Я не знаю, какой смысл Вы пытаетесь вложить в слово "компания". Это другое ООО.
Есть репутация. И есть заявления вроде:
Всем, кто обращался по поводу возврата средств — мы вернули (о чем здесь отписывали те, кому вернули).
И есть те, чьи вопросы (даже в этой теме) остались без ответа.. (а ещё есть те, кто давно уже забил и пошёл дальше)
Может он решил подождать 3 года, когда все обязательства по деньгам станут ничтожными. Кстати, в каком году с ними это всё произошло?
"это" произошло с другим "ООО".. Т.е. у "новой" (текущей) компании нет "тех" обязательств.
Но на основном проблема остается. Даже после очистки, по нажатию " Перейти в админ. панель" вылазит эта табличка.
В .htaccess поискать по подстроке handler
Если ISPManager.. - включить php (галка) для домена в свойствах
(для, других панелей - навскидку не скажу)
Самая длинная дискуссия на эту тему здесь.
Ayavryk, спасибо.. видел и это..
Цитата из поста (дабы не разрывать - приведу целиком):
Антипаттерном по мнению автора презентации являются "фантомные" файлы, возникающие при рассинхроне FS и БД при удалении, или транзакции (файл уже сохранён, а транзакция откатывается, или наоборот).
ИМХО, "проблема" решается простым сборщиком мусора (пишется на коленке), правильным порядком сохранения (файл, база) и, при необходимости, lock-ом при обновлении.
В комментариях к
http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/ Петр Зайцев (цитата, правда, 2010 года):
Из минусов такого подхода:
- в оперативке вместо "полезных" данных (индексы, временные таблицы, кэш) висят файлы (если нет - опять же читается с диска (БД), а затем - отдаётся веб-серверу. Вместо прямого диск->веб-сервер).. При этом в случае хранения в файлах часто используемые кэшируются на уровне FS. При необходимости можно tmpfs подмонтировать
- нужно извращаться, чтобы отдать файл браузеру (тут речь о "стандартном" L(A|E)MP, а не про встроенный в СУБД web-сервер или плюшки вроде FILESTREAM) - php, коннект к базе, получение файла, его отдача (vs отдача напрямую Nginx-ом из FS)
В общем, метод имеет право на жизнь, наверняка успешно применяется (в определённых условиях), но с учётом:
и
Но есть маленькая проблема, сайт довольно крупный, планируеться большая посещаемости, и когда аватарок будет допустим 100.000, получаеться будет 400 папок. Что тоже уже много.
я бы не рекомендовал ТС-у использовать этот вариант.