Я бы не хотел, чтобы продукты были в этих сложных высокотехнологичных упаковках. Мало того, что технология и материалы добавляются к стоимости продукта, так еще и магазин будет тратиться на эти сложные питающие установки — и это тоже добавится к цене продукта.
Для сравнения: сейчас довольно-таки большая часть цены любого известного продукта — реклама. То есть мы платим за то, чтобы огромные баннеры загораживали номера домов, и чтобы в лицо нам совали цветные бумажки.
Теперь еще будем платить за, чтобы продукты вызывали у нас эпилептические припадки.
Сильно ли можно выиграть в скорости, храня редкоменяющиеся данные в колоночной БД, а постоянно растущие таблицы (например, теги или свзяи) в обычной реляционной? Учитывая возрастающее потребление памяти и необходимость запущенному скрипту держать два соединения.
Как у колоночных СУБД обстоит дело с масштабируемостью?
Наполнялся как-то мой 320-гиговый жесткий двд-рипами. И пришел ко мне как-то друг да попросил поделиться накопленным. И скопировал я ему все фильмы со скорость 320 гигабайт в секунду безвозмездно. Ведь собирался я новый комп и жесткий заодно брать в время ближайшее.
C замком на три цифры справится и человек. Для начала пробуем комбинацию 000. А затем подбираем. Любой сможет подбирать 1 комбинацию в секунду, т.е. справится за 1000 секунд или 16 минут и 40 секунд.
Вряд ли по задержке сигнала (она для 2 и для 20 метров будет почти одинаковой), скорее по уровню сигнала, который как раз таки выправляется этим «репитер»
Для сравнения: сейчас довольно-таки большая часть цены любого известного продукта — реклама. То есть мы платим за то, чтобы огромные баннеры загораживали номера домов, и чтобы в лицо нам совали цветные бумажки.
Теперь еще будем платить за, чтобы продукты вызывали у нас эпилептические припадки.
Как у колоночных СУБД обстоит дело с масштабируемостью?