Заказать будет дешевле, но разница в цене не катастрофа.
100 баксов разницы (199+50 доставка против 35) за то что бы не ждать месяц доставки, не рисковать с почтой, иметь гарантию и возможность манибека. Определённо придется подумать какой вариант выбрать.
То есть Вам нравится идея еще более кардинального выноса статистики:) Вы не согласны только с половинчатым решением?:)
На одной чаше весов дергать 2 таблицы при показе статьи/ленты статей, на другой дергать всего 1 таблицу… хм… если вывод статей в приоритете, то второй вариант. Если нам надо часто считать статистику, то первый.
Но плечи у этих весов разные.
Речь идет о том, что мы должны быстро отдавать контент с максимальной скоростью…
Именно поэтому и предлагаем как альтернативу — работу с небольшими объемами данными для скорости.
То что отвечают на форуме — неплохо конечно.
А не так тут то, что эта ситуация должна была быть официально разъяснена в пресс-релизе заранее, а не по ходу пьесы на форуме в ответ на вопросы.
Любопытно.
Если бы название конторы осталось бы прежним, а сменились бы учредители/акционеры?
Если бы учредители/акционеры остались бы прежними, а сменился бы весь технический персонал?
Если бы офис переехал?
Если бы договор изменился?
Если бы ТМ другая появилась бы?
Много чего может случиться, а Вас только смена названия ооо беспокоит?:)
p.s.: у нас банк где р/с за несколько лет раза 4 переименовался, купился/продался и переехал:) петровский-мдм-вефк-петровский-открытие. Ничего, живы.
Если вы физическое лицо, то предпринимать ничего не нужно.
Если вы юридическое лицо, то до 01.08.2012 вам нужно перезаключить договор с компанией ООО «Клаудгейт Платформа».
В этих случаях ваши серверы продолжат работать как работали и совершать переезд не потребуется.
Платформу Скалакси далее будет обслуживать компания Клаудейт, по тем же ценам, с теми же условиями.
Именно по Вашему сообщению никакого особого «рашен бизнеса» тут не видно.
Типично западное поведение — родили дочку и отдали ей направление, предложив переоформить договора.
У меня сайт в коме и сша, зареган на левые данные более 5 лет назад. Никто слова лишнего не сказал и не написал.
Неуловимый джо.
Плюс в худшем случае при левых данных в ком-е и проблем — Вам надо будет доказать, допустим, оплату домена… но по регламенту com зоны Вы вполне имеете право иметь там домен. А эта регистрация EU — это совсем другое, т.к. не гражданин там доменом владеть не может в принципе, если раскрутитесь в EU — Вам просто не на что будет их менять для легализации.
вы через чур щепетильны по этому поводу.
Мы-то ладно, главное что бы регистратор не был щепетилен:)
Не обязательно. Даже если забыть о хранимках, то update select никто не отменял.
Отдельные таблицы — это далее получаем доп запросы или джойны. Чем больше данных, и чем меньше память сервера тем больше желание сделать все более быстрее.
Именно — быстрее.
Если Вы выносите кол-во комментов и просмотров (часто обновляющуюся информацию) из таблицы новостей (редко обновляющуяся информация), то таблица новостей (огромного размера) перестает у Вас дергаться с дикой частотой (особенно если Вы просмотры логируете), а дергаться начинает мелкая таблица (со страшной скоростью, в меру ее размера), как следствие ускоряется и апдейт и сортировка и выборка… особенно по кол-ву комментариев/просмотров.
Тип таблицы — это «дело наживное». Какой быстрее работает, такой и будет.
Разница в типах локов таблиц это наживное дело?
Лишние запросы — это ЛИШНИЕ запросы.
А быстрые запросы — это БЫСТРЫЕ запросы. Вчера были маленькие но по 2, а сегодня большие но по 5:)
в случае с высокими нагрузками можно и на счет кэширующих систем холивор развести.
То о чем мы говорим, это не кэширование. Тут нет редких выборок и дублирования данных и нет ситуации когда все дружно начинают лезть в кэш, в общем как раз нет типичных проблем кэширования. Просто часто обновляемые данные выносятся в отдельный блок для более быстрой с ними работы, по сути все не статические данные хранятся в отдельной таблице, это скорее можно сравнить не с кэшированием, а с простановкой индексов если уж на то пошло.
Триггеры в таком применении, для улучшения производительности плохи тем, что срабатывают каждый раз, особенно если речь об myisam, где лочится таблица, а не строка.
Обычно для решения этой же проблемы делаем
или а) по крону апдейтим счетчики в основной таблице, по крону, а не по триггерам, т.к. крон проще контроллировать и запускать раз на 10 комментариев например, а не на каждый.
или б) для счетчиков выделяется полностью отдельная таблица, занимающая мало места, только ид*нум_комментс*_нум_виевз, без всяких текстовых и прочих лишних полей.
или в) комментарии из таблицы комментариев пишутся так же в таблицу без комментариев такой же структуры. одним запросом больше при записи, но зато кол-во комментариев выгребать в случае чего намного быстрее и проще можно.
А потом будет топик в «я негодую» вида «отобрали домен бюрократы».
С ru доменами помнится была волна — регить на левые данные, а потом когда дело дошло до переоформления и/или претензий — оппа, а домен-то и не отстоять.
Не факт.
Владеем девайсом на андроиде — считаем его лучшим, однако 4.1 это просто небольшая эволюция.
След. девайс будет на wp8, но презентация сурфейса неинтересна, а вп8 ничего нового не говорит.
Макбук лично нам на фиг нужен, но ретина это очень интересно, хотя и странно реализована.
По поводу «махинаций» — зря Вы в мифы записали на базе такой простой аргументации.
Премирование должно быть осмысленным и стимулирующим.
Наибольший стимул это или получение денег или улучшение взаимоотношений.
Наибольший смысл в премиях это когда они выдаются тому, чью работа известна.
И то и другое подразумевает близкое сотрудничество, таким образом как раз естественным будет замыкание премий внутри узких ячеек «Маша -> Петя -> Вася -> Маша», где люди друг друга знают (есть смысл улучшать взаимоотношения и надежда получить деньги) и знают качество работы друг друга (не премировать же неизвестного дворника из соседнего корпуса), а Вы их на ковер и увольнять за махинации.
В остальном — по сути это какой-то «нирыбанимясо» фриланс. Улучшить горизонтальные связи тем, что в соседнем отделе тебе помогут за премиальные деньги? С одной стороны это тупо переквалификация любого работника в менеджера («я лучше спихну свою проблему в соседний отдел за 100р, а сам в это время левака на 200р сделаю») или местный консультационный центр — в результате соседний отдел будет всем помогать (10 вовремя спасенных в бухгалтерии кактусов это 10 премий, а оклад он один) но ничего больше в плане должностных обязанностей.
В общем — кесарю кесарево, цезарю цезарево, а ссср-ную систему лучше оставить в ссср.
По факту — экономия на спичках, жертва бОльшего во имя меньшего.
Даже если забыть о том, что у современного смарта гигагерц на борту…
То время инициализации скрипта даже будучи сокращенным на порядок (а отказ от поддержки старого кода время _инициализации_ сократит не больше чем раза в 2 почти наверняка), на время общей загрузки и рендеринга повлияет жалкими долями процента.
0.01 секунды или 0.011 секунды большая разница?
ну понеслась… сейчас докатимся до того, что фотки надо делать только на средний формат:-)
по факту, если снимать без зума, то качество видео со смарта (сгс2) при норм освещении не хуже чем с фуллхд хорошего панасоника (покупали незадолго ло сгс2), в плюсах удобный формат (а не кривой пал/нтсц который еще не каждый редактор возьмет), объем файлов (мп4 сразу это вам не тут!). Отсутствие юзабилити и не в последнюю очередб неудобность хвата портит 80% всего.
Все что надо сделать (реально сделать) это что бы смартфоны снимали бы горизонтальное видео при вертикальном положении.
Современные супертонкие суперлегкие смарты и так тяжело держать, а уж в горизонтальном положении это вообще ппц, особенно при съемке видео, пытаясь одновременно на экран не нажать случайно и не выронить из руки и камеру пальцами не закрыть.
Юзабилити как видео/фото камеры у смартов очень низки, вертикальный хват это хоть немного исправляет, так что верт.видео это не по приколу, это по сути вынужденная мера.
100 баксов разницы (199+50 доставка против 35) за то что бы не ждать месяц доставки, не рисковать с почтой, иметь гарантию и возможность манибека. Определённо придется подумать какой вариант выбрать.
Но плечи у этих весов разные.
Именно поэтому и предлагаем как альтернативу — работу с небольшими объемами данными для скорости.
А не так тут то, что эта ситуация должна была быть официально разъяснена в пресс-релизе заранее, а не по ходу пьесы на форуме в ответ на вопросы.
Если бы название конторы осталось бы прежним, а сменились бы учредители/акционеры?
Если бы учредители/акционеры остались бы прежними, а сменился бы весь технический персонал?
Если бы офис переехал?
Если бы договор изменился?
Если бы ТМ другая появилась бы?
Много чего может случиться, а Вас только смена названия ооо беспокоит?:)
p.s.: у нас банк где р/с за несколько лет раза 4 переименовался, купился/продался и переехал:) петровский-мдм-вефк-петровский-открытие. Ничего, живы.
Типично западное поведение — родили дочку и отдали ей направление, предложив переоформить договора.
Плюс в худшем случае при левых данных в ком-е и проблем — Вам надо будет доказать, допустим, оплату домена… но по регламенту com зоны Вы вполне имеете право иметь там домен. А эта регистрация EU — это совсем другое, т.к. не гражданин там доменом владеть не может в принципе, если раскрутитесь в EU — Вам просто не на что будет их менять для легализации.
Мы-то ладно, главное что бы регистратор не был щепетилен:)
Именно — быстрее.
Если Вы выносите кол-во комментов и просмотров (часто обновляющуюся информацию) из таблицы новостей (редко обновляющуяся информация), то таблица новостей (огромного размера) перестает у Вас дергаться с дикой частотой (особенно если Вы просмотры логируете), а дергаться начинает мелкая таблица (со страшной скоростью, в меру ее размера), как следствие ускоряется и апдейт и сортировка и выборка… особенно по кол-ву комментариев/просмотров.
Разница в типах локов таблиц это наживное дело?
А быстрые запросы — это БЫСТРЫЕ запросы. Вчера были маленькие но по 2, а сегодня большие но по 5:)
То о чем мы говорим, это не кэширование. Тут нет редких выборок и дублирования данных и нет ситуации когда все дружно начинают лезть в кэш, в общем как раз нет типичных проблем кэширования. Просто часто обновляемые данные выносятся в отдельный блок для более быстрой с ними работы, по сути все не статические данные хранятся в отдельной таблице, это скорее можно сравнить не с кэшированием, а с простановкой индексов если уж на то пошло.
Обычно для решения этой же проблемы делаем
или а) по крону апдейтим счетчики в основной таблице, по крону, а не по триггерам, т.к. крон проще контроллировать и запускать раз на 10 комментариев например, а не на каждый.
или б) для счетчиков выделяется полностью отдельная таблица, занимающая мало места, только ид*нум_комментс*_нум_виевз, без всяких текстовых и прочих лишних полей.
или в) комментарии из таблицы комментариев пишутся так же в таблицу без комментариев такой же структуры. одним запросом больше при записи, но зато кол-во комментариев выгребать в случае чего намного быстрее и проще можно.
С ru доменами помнится была волна — регить на левые данные, а потом когда дело дошло до переоформления и/или претензий — оппа, а домен-то и не отстоять.
Владеем девайсом на андроиде — считаем его лучшим, однако 4.1 это просто небольшая эволюция.
След. девайс будет на wp8, но презентация сурфейса неинтересна, а вп8 ничего нового не говорит.
Макбук лично нам на фиг нужен, но ретина это очень интересно, хотя и странно реализована.
Премирование должно быть осмысленным и стимулирующим.
Наибольший стимул это или получение денег или улучшение взаимоотношений.
Наибольший смысл в премиях это когда они выдаются тому, чью работа известна.
И то и другое подразумевает близкое сотрудничество, таким образом как раз естественным будет замыкание премий внутри узких ячеек «Маша -> Петя -> Вася -> Маша», где люди друг друга знают (есть смысл улучшать взаимоотношения и надежда получить деньги) и знают качество работы друг друга (не премировать же неизвестного дворника из соседнего корпуса), а Вы их на ковер и увольнять за махинации.
В остальном — по сути это какой-то «нирыбанимясо» фриланс. Улучшить горизонтальные связи тем, что в соседнем отделе тебе помогут за премиальные деньги? С одной стороны это тупо переквалификация любого работника в менеджера («я лучше спихну свою проблему в соседний отдел за 100р, а сам в это время левака на 200р сделаю») или местный консультационный центр — в результате соседний отдел будет всем помогать (10 вовремя спасенных в бухгалтерии кактусов это 10 премий, а оклад он один) но ничего больше в плане должностных обязанностей.
В общем — кесарю кесарево, цезарю цезарево, а ссср-ную систему лучше оставить в ссср.
Даже если забыть о том, что у современного смарта гигагерц на борту…
То время инициализации скрипта даже будучи сокращенным на порядок (а отказ от поддержки старого кода время _инициализации_ сократит не больше чем раза в 2 почти наверняка), на время общей загрузки и рендеринга повлияет жалкими долями процента.
0.01 секунды или 0.011 секунды большая разница?
и есть еще момент, иногда не хватает широкого угла… ну или высокого учитывая контекст)))
по факту, если снимать без зума, то качество видео со смарта (сгс2) при норм освещении не хуже чем с фуллхд хорошего панасоника (покупали незадолго ло сгс2), в плюсах удобный формат (а не кривой пал/нтсц который еще не каждый редактор возьмет), объем файлов (мп4 сразу это вам не тут!). Отсутствие юзабилити и не в последнюю очередб неудобность хвата портит 80% всего.
Современные супертонкие суперлегкие смарты и так тяжело держать, а уж в горизонтальном положении это вообще ппц, особенно при съемке видео, пытаясь одновременно на экран не нажать случайно и не выронить из руки и камеру пальцами не закрыть.
Юзабилити как видео/фото камеры у смартов очень низки, вертикальный хват это хоть немного исправляет, так что верт.видео это не по приколу, это по сути вынужденная мера.