Вряд ли Вы мне докажете, что такая ситуация была в рамках одной транзакции.
Не получится доказать, ибо данные вставляются и размер таблицы растет и ID уже не вернуть. Но у транзакций есть также весомый минус — после откатов таблица становится фрагментированной и необходимо её перестраивать, что на больших таблицах крайне долгая операция и делается посредством темповой таблицы.
Согласен что момент спорный, но моя практика показывает, что после активного добавления/удаления таблиц в режиме «один файл» и добавления/удаления из существующих произвидительность серьёзно снижается, даже после ALTER TABLE… В основном за счет фрагментации (других причин не вижу), в случае отдельных файлов такой проблемы нету.
Скорее правило:
Один пользователь на проэкт, да и это тоже не подходит.
Куда разумнее под «морду» давать ограниченную учетку без дропов, грантов и прочего, а для обновления базы создавать другую учетку, пользоваться рутом не комильфо.
MyISAM имеет существенный недостаток, а именно блокировка всей таблицы:
— Если таблица «почти» рид-онли, то преимущество на стороне MyISAM, но если в таблицу по несколько десятков запросов на чтение и запись, то производительность очень существенно ухудшится.
— При множественных апдейтах больших таблиц, InnoDB может выигрывать порядок-другой при использовании транзакций.
— …
Вывод: лучше всего знать все плюсы/минусы различных типов таблиц и использовать их по назначению, тогда можно добиться максимальной производительности базы.
Это лечится, основной затык ИнноДБ — это быстрорастущий со временем файл базы, ибо по умолчанию он создает все таблицы и базы в одном файле, что для больших баз плохо.
по поводу операторских блокировок, насколько я наслышан, в России они запрещены, соотвественно я имею полное право такие блокировки снимать, разве нет?
После приобретения железки я имею право делать с ней всё что угодно, хоть ставить кастомную прошивку, хоть переехать катком. И никакая компания не имеет права ограничивать меня в этом праве.
Имхо, тоже самое касается и игроков в CS, я бы даже сказал что это даже лучше. Для успеха в CS нужна слаженная работа команды, что для стартапа даже важнее чем просто скил одно человека в команде.
«Недодержать» можно не только в смысле «недоэкспонировать» ;-)
В остальном согласен, среди фотографов любителей такой термин ходит, в других кругах к сожалению не общался. Только с «проффесионалами».
P.S. translate.google.com тоже не самый надёжный источник, ибо можно «предложить свой вариант».
Это не меняет тот факт, что зеркало еще не скоро станет пережитком, ибо пока прицелится вручную по экрану достаточно сложно, особенно при ярком солнце или при плохом осчещении (вечер/ночь).
Когда динамический диапазон матрицы значительно увеличат, а экран будет иметь плотность пикселей 300ppi и не будет выгорать на солнце — тогда можно будет отказаться от зеркала.
Зеркало во время съемки подымается, поэтому потери светосилы нету ;)
LiveView — это конечно хорошо, но он не позволяет увидеть столько деталей, сколько можно увидеть через видоискатель, да и «прицелиться» по экрану при F2.8 и ручной фокусировке будет достаточно проблематично, что уже говорить про F1.8.
неплохая железка, купил себе и не жалею
производительности хватает, торренты тянет на 11.3Мб, между компами 300-500Мбит по лану, про скорость вайфай ничего не могу сказать
Не получится доказать, ибо данные вставляются и размер таблицы растет и ID уже не вернуть. Но у транзакций есть также весомый минус — после откатов таблица становится фрагментированной и необходимо её перестраивать, что на больших таблицах крайне долгая операция и делается посредством темповой таблицы.
Вероятно всё же INSERT IGNORE, ибо обычной инсерт должен делать сразу SELECT по ID.
Один пользователь на проэкт, да и это тоже не подходит.
Куда разумнее под «морду» давать ограниченную учетку без дропов, грантов и прочего, а для обновления базы создавать другую учетку, пользоваться рутом не комильфо.
— Если таблица «почти» рид-онли, то преимущество на стороне MyISAM, но если в таблицу по несколько десятков запросов на чтение и запись, то производительность очень существенно ухудшится.
— При множественных апдейтах больших таблиц, InnoDB может выигрывать порядок-другой при использовании транзакций.
— …
Вывод: лучше всего знать все плюсы/минусы различных типов таблиц и использовать их по назначению, тогда можно добиться максимальной производительности базы.
В остальном согласен, среди фотографов любителей такой термин ходит, в других кругах к сожалению не общался. Только с «проффесионалами».
P.S. translate.google.com тоже не самый надёжный источник, ибо можно «предложить свой вариант».
Когда динамический диапазон матрицы значительно увеличат, а экран будет иметь плотность пикселей 300ppi и не будет выгорать на солнце — тогда можно будет отказаться от зеркала.
LiveView — это конечно хорошо, но он не позволяет увидеть столько деталей, сколько можно увидеть через видоискатель, да и «прицелиться» по экрану при F2.8 и ручной фокусировке будет достаточно проблематично, что уже говорить про F1.8.
производительности хватает, торренты тянет на 11.3Мб, между компами 300-500Мбит по лану, про скорость вайфай ничего не могу сказать