Дропбокс тоже на старте даёт только 2Гб (http://www.dropbox.com/features). И в wuala Вы свой объём тоже можете увеличить, привлекая новых пользователей или отдавая кусочек своего винчестера для ихнего облака.
И я не сказал, что Дропбокс — это плохо.
Просто для моих задач гораздо лучше подошёл 1Гб надёжно шифруемого пространства, чем просто 2Гб места.
А откуда ж браться разнице? Парсер, он же не дурак. Он один раз всё парсит, а потом просто выполняет :)
А с точки зрения выполнения конструкции почти одинаковые.
это понятно. но настолько ли отсутствие конкатенации лучше, что компенсирует в 7 раз большую «медленность» конструкции $row[id] по сравнению с $row['id']?
Потому, что при создании таблицы мы заранее не знаем, какие данные в ней будут. И если сказано «будем хранить 10 символов», надо понимать «может понадобиться до 30 байт». При DYNAMIC-формате строк (для InnoDB, MyISAM и др.) всё нормально, лишнего не скушается, ограничивается только максимальная длина строки.
А MEMORY-таблицы всегда имеют FIXED-формат строк. Потому под любую строку будет выделяться <макс-длина-строки> * 3 байт места.
И да, я ошибся, 65536 * 3 = 192кб, а не 196. Сорри.
Ничего не будет. тут как раз всё логично, при аварийном завершении завершатся и все сессии.
нельзя в таблицах типа MEMRORY хранить жизненно важные данные.
А Вы пробовали создать таблицу запросом, приведённым в статье? Как ни крути, выходит
ERROR 1163 (42000): The used table type doesn't support BLOB/TEXT columns
Видио из-за того, что для utf8 кодировки используется по 3 байта на символ, и VARCHAR(65536) — это совсем не 65536 байт.
А ещё, если не ошибаюсь, в MySQL есть лимит размера данных одной строки в 64кб (за исключением BLOB полей, но они как раз в MEMORY-таблицах и не поддерживаются).
А ещё «MEMORY tables use a fixed-length row-storage format. Variable-length types such as VARCHAR are stored using a fixed length» (http://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html),
т.е. даже если Ваши данные всего несколько символов — в таблице они всё равно откудают место под 65536-символов = 196кб
ага, и этого тоже никто не заметит?
И я не сказал, что Дропбокс — это плохо.
Просто для моих задач гораздо лучше подошёл 1Гб надёжно шифруемого пространства, чем просто 2Гб места.
Всего лишь вопрос предпочтений.
Они файлы шифруют ещё перед загрузкой, на стороне клиента.
Мой метод: не пользоваться Дропбоксом.
А с точки зрения выполнения конструкции почти одинаковые.
Я Вам доказывать ничего и не собираюсь в общем-то…
Спасибо огромное! :)
«текст {$row['id']} текст» — про такое не знал :\
echo «текст ». $row['id']. " текст"
лучше чем
echo «текст $row[id] текст»
так?
а использование «текст $row[id] текст» — тоже плохо?
Заранее спасибо!
А там сказано:
Так что я не перепутал VARCHAR и CHAR в данном конкретном случае (использование MEMORY-таблиц).
скушает 64кб памяти, хотя сохранили мы всего 2 символа.
А MEMORY-таблицы всегда имеют FIXED-формат строк. Потому под любую строку будет выделяться <макс-длина-строки> * 3 байт места.
И да, я ошибся, 65536 * 3 = 192кб, а не 196. Сорри.
нельзя в таблицах типа MEMRORY хранить жизненно важные данные.
ERROR 1163 (42000): The used table type doesn't support BLOB/TEXT columns
Видио из-за того, что для utf8 кодировки используется по 3 байта на символ, и VARCHAR(65536) — это совсем не 65536 байт.
А ещё, если не ошибаюсь, в MySQL есть лимит размера данных одной строки в 64кб (за исключением BLOB полей, но они как раз в MEMORY-таблицах и не поддерживаются).
А ещё «MEMORY tables use a fixed-length row-storage format. Variable-length types such as VARCHAR are stored using a fixed length» (http://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html),
т.е. даже если Ваши данные всего несколько символов — в таблице они всё равно откудают место под 65536-символов = 196кб