Тут ключевой момент в том, что Вы пишите в анкетах, а следовательно — Вы даете информацию.
Какую бы Вы чушь там не написали — написать ее было Вашим мотивированным решением, которое демонстрирует определённый паттерн поведения, а следовательно предоставляет информацию для выводов. И даже если Вы ошиблись при указании фио и адреса — косвенно Вы предоставите другие данные, которые могут быть использованы для Вашего удобства для того что бы получить о Вас информацию.
Лично у нас терминал с надписью «сбербанк» не принял ни альфу ни авангард. Подумали что глюк магазина какой-то, но теперь в голову приходят мысли о проблемах все-таки у сбера.
Спасибо за тему, приглядываемся сами, было любопытно почитать, однако…
Живу в Приморском районе, в Северо-Западном регионе Санкт-Петербурга (не в области), тут пока что мало торговых центров и карточки мало где принимают.
А Вы точно в приморском районе в СПб живете? В нем сейчас сложнее найти магазин где карты НЕ принимают, особенно если речь о ТЦ. Из всех магазинов вокруг вспоминается только «полушка», где действительно берут только нал ну и рыночного типа лавки с набором мелких ИП, больше тупо нечего придумать даже постаравшись, Окей, лента, леруа-мерлен, прима, ленд, семья, континент, карусель, все азс и так далее — везде карты берут на отлично.
Дело-то было не в прибыли (что недостача компенсировала), а в том что бы бензин попадал только кому надо (что недостачей не компенсируется).
К тому же подозрительная активность может быть только верхушкой айсберга.
Заказать будет дешевле, но разница в цене не катастрофа.
100 баксов разницы (199+50 доставка против 35) за то что бы не ждать месяц доставки, не рисковать с почтой, иметь гарантию и возможность манибека. Определённо придется подумать какой вариант выбрать.
То есть Вам нравится идея еще более кардинального выноса статистики:) Вы не согласны только с половинчатым решением?:)
На одной чаше весов дергать 2 таблицы при показе статьи/ленты статей, на другой дергать всего 1 таблицу… хм… если вывод статей в приоритете, то второй вариант. Если нам надо часто считать статистику, то первый.
Но плечи у этих весов разные.
Речь идет о том, что мы должны быстро отдавать контент с максимальной скоростью…
Именно поэтому и предлагаем как альтернативу — работу с небольшими объемами данными для скорости.
То что отвечают на форуме — неплохо конечно.
А не так тут то, что эта ситуация должна была быть официально разъяснена в пресс-релизе заранее, а не по ходу пьесы на форуме в ответ на вопросы.
Любопытно.
Если бы название конторы осталось бы прежним, а сменились бы учредители/акционеры?
Если бы учредители/акционеры остались бы прежними, а сменился бы весь технический персонал?
Если бы офис переехал?
Если бы договор изменился?
Если бы ТМ другая появилась бы?
Много чего может случиться, а Вас только смена названия ооо беспокоит?:)
p.s.: у нас банк где р/с за несколько лет раза 4 переименовался, купился/продался и переехал:) петровский-мдм-вефк-петровский-открытие. Ничего, живы.
Если вы физическое лицо, то предпринимать ничего не нужно.
Если вы юридическое лицо, то до 01.08.2012 вам нужно перезаключить договор с компанией ООО «Клаудгейт Платформа».
В этих случаях ваши серверы продолжат работать как работали и совершать переезд не потребуется.
Платформу Скалакси далее будет обслуживать компания Клаудейт, по тем же ценам, с теми же условиями.
Именно по Вашему сообщению никакого особого «рашен бизнеса» тут не видно.
Типично западное поведение — родили дочку и отдали ей направление, предложив переоформить договора.
У меня сайт в коме и сша, зареган на левые данные более 5 лет назад. Никто слова лишнего не сказал и не написал.
Неуловимый джо.
Плюс в худшем случае при левых данных в ком-е и проблем — Вам надо будет доказать, допустим, оплату домена… но по регламенту com зоны Вы вполне имеете право иметь там домен. А эта регистрация EU — это совсем другое, т.к. не гражданин там доменом владеть не может в принципе, если раскрутитесь в EU — Вам просто не на что будет их менять для легализации.
вы через чур щепетильны по этому поводу.
Мы-то ладно, главное что бы регистратор не был щепетилен:)
Не обязательно. Даже если забыть о хранимках, то update select никто не отменял.
Отдельные таблицы — это далее получаем доп запросы или джойны. Чем больше данных, и чем меньше память сервера тем больше желание сделать все более быстрее.
Именно — быстрее.
Если Вы выносите кол-во комментов и просмотров (часто обновляющуюся информацию) из таблицы новостей (редко обновляющуяся информация), то таблица новостей (огромного размера) перестает у Вас дергаться с дикой частотой (особенно если Вы просмотры логируете), а дергаться начинает мелкая таблица (со страшной скоростью, в меру ее размера), как следствие ускоряется и апдейт и сортировка и выборка… особенно по кол-ву комментариев/просмотров.
Тип таблицы — это «дело наживное». Какой быстрее работает, такой и будет.
Разница в типах локов таблиц это наживное дело?
Лишние запросы — это ЛИШНИЕ запросы.
А быстрые запросы — это БЫСТРЫЕ запросы. Вчера были маленькие но по 2, а сегодня большие но по 5:)
в случае с высокими нагрузками можно и на счет кэширующих систем холивор развести.
То о чем мы говорим, это не кэширование. Тут нет редких выборок и дублирования данных и нет ситуации когда все дружно начинают лезть в кэш, в общем как раз нет типичных проблем кэширования. Просто часто обновляемые данные выносятся в отдельный блок для более быстрой с ними работы, по сути все не статические данные хранятся в отдельной таблице, это скорее можно сравнить не с кэшированием, а с простановкой индексов если уж на то пошло.
Триггеры в таком применении, для улучшения производительности плохи тем, что срабатывают каждый раз, особенно если речь об myisam, где лочится таблица, а не строка.
Обычно для решения этой же проблемы делаем
или а) по крону апдейтим счетчики в основной таблице, по крону, а не по триггерам, т.к. крон проще контроллировать и запускать раз на 10 комментариев например, а не на каждый.
или б) для счетчиков выделяется полностью отдельная таблица, занимающая мало места, только ид*нум_комментс*_нум_виевз, без всяких текстовых и прочих лишних полей.
или в) комментарии из таблицы комментариев пишутся так же в таблицу без комментариев такой же структуры. одним запросом больше при записи, но зато кол-во комментариев выгребать в случае чего намного быстрее и проще можно.
А потом будет топик в «я негодую» вида «отобрали домен бюрократы».
С ru доменами помнится была волна — регить на левые данные, а потом когда дело дошло до переоформления и/или претензий — оппа, а домен-то и не отстоять.
arbitrage.webmoney.ru/asp/claims.asp?wmid=884063168167
forum.webmoney.ru/index.php?/topic/16571-884063168167
Купил пылесос, а потом еще 2 недели тебе в рекламе душу травят более хорошими и более дешевыми моделями:)
Какую бы Вы чушь там не написали — написать ее было Вашим мотивированным решением, которое демонстрирует определённый паттерн поведения, а следовательно предоставляет информацию для выводов. И даже если Вы ошиблись при указании фио и адреса — косвенно Вы предоставите другие данные, которые могут быть использованы
для Вашего удобствадля того что бы получить о Вас информацию.forum.searchengines.ru/showpost.php?p=10567908&postcount=673
Тогда понятно, но там у Вас вообще магазинов считай нет:)
А Вы точно в приморском районе в СПб живете? В нем сейчас сложнее найти магазин где карты НЕ принимают, особенно если речь о ТЦ. Из всех магазинов вокруг вспоминается только «полушка», где действительно берут только нал ну и рыночного типа лавки с набором мелких ИП, больше тупо нечего придумать даже постаравшись, Окей, лента, леруа-мерлен, прима, ленд, семья, континент, карусель, все азс и так далее — везде карты берут на отлично.
К тому же подозрительная активность может быть только верхушкой айсберга.
100 баксов разницы (199+50 доставка против 35) за то что бы не ждать месяц доставки, не рисковать с почтой, иметь гарантию и возможность манибека. Определённо придется подумать какой вариант выбрать.
Но плечи у этих весов разные.
Именно поэтому и предлагаем как альтернативу — работу с небольшими объемами данными для скорости.
А не так тут то, что эта ситуация должна была быть официально разъяснена в пресс-релизе заранее, а не по ходу пьесы на форуме в ответ на вопросы.
Если бы название конторы осталось бы прежним, а сменились бы учредители/акционеры?
Если бы учредители/акционеры остались бы прежними, а сменился бы весь технический персонал?
Если бы офис переехал?
Если бы договор изменился?
Если бы ТМ другая появилась бы?
Много чего может случиться, а Вас только смена названия ооо беспокоит?:)
p.s.: у нас банк где р/с за несколько лет раза 4 переименовался, купился/продался и переехал:) петровский-мдм-вефк-петровский-открытие. Ничего, живы.
Типично западное поведение — родили дочку и отдали ей направление, предложив переоформить договора.
Плюс в худшем случае при левых данных в ком-е и проблем — Вам надо будет доказать, допустим, оплату домена… но по регламенту com зоны Вы вполне имеете право иметь там домен. А эта регистрация EU — это совсем другое, т.к. не гражданин там доменом владеть не может в принципе, если раскрутитесь в EU — Вам просто не на что будет их менять для легализации.
Мы-то ладно, главное что бы регистратор не был щепетилен:)
Именно — быстрее.
Если Вы выносите кол-во комментов и просмотров (часто обновляющуюся информацию) из таблицы новостей (редко обновляющуяся информация), то таблица новостей (огромного размера) перестает у Вас дергаться с дикой частотой (особенно если Вы просмотры логируете), а дергаться начинает мелкая таблица (со страшной скоростью, в меру ее размера), как следствие ускоряется и апдейт и сортировка и выборка… особенно по кол-ву комментариев/просмотров.
Разница в типах локов таблиц это наживное дело?
А быстрые запросы — это БЫСТРЫЕ запросы. Вчера были маленькие но по 2, а сегодня большие но по 5:)
То о чем мы говорим, это не кэширование. Тут нет редких выборок и дублирования данных и нет ситуации когда все дружно начинают лезть в кэш, в общем как раз нет типичных проблем кэширования. Просто часто обновляемые данные выносятся в отдельный блок для более быстрой с ними работы, по сути все не статические данные хранятся в отдельной таблице, это скорее можно сравнить не с кэшированием, а с простановкой индексов если уж на то пошло.
Обычно для решения этой же проблемы делаем
или а) по крону апдейтим счетчики в основной таблице, по крону, а не по триггерам, т.к. крон проще контроллировать и запускать раз на 10 комментариев например, а не на каждый.
или б) для счетчиков выделяется полностью отдельная таблица, занимающая мало места, только ид*нум_комментс*_нум_виевз, без всяких текстовых и прочих лишних полей.
или в) комментарии из таблицы комментариев пишутся так же в таблицу без комментариев такой же структуры. одним запросом больше при записи, но зато кол-во комментариев выгребать в случае чего намного быстрее и проще можно.
С ru доменами помнится была волна — регить на левые данные, а потом когда дело дошло до переоформления и/или претензий — оппа, а домен-то и не отстоять.