McBernar

Большинство софта не умеет читать информацию из архивов, поэтому при попытке открыть файл из архива или запустить программу он извлекается из архива в папку Temp находящуюся в профиле пользователя, и уже оттуда используется. После чего удаляется, или не удаляется, как повезет.

Поэтому да - в большинстве случаев появляется. Но тут еще много зависит от того каким образом вы работаете с архивом.

Нашёл!
Автор: mindw0rk
Рассказ: Незнакомец по ту сторону сети
Рассказ не длинный.

https://jsfiddle.net/Lk0p90tc/

<div>
  Рассчитаем стоимость обслуживания за 15 минут
</div>

div {
  width: 250px;
  height: 70px;
  border-radius: 3px;
  display: flex;
  align-items: center;
  justify-content: center;
  text-align: center;
  text-transform: uppercase;
  font-size: 12px;
  font-family: sans-serif;
  padding: 5px 40px;
  color: #fff;
  background: #EBA146 no-repeat;
  background-image:
    radial-gradient(circle at center, #fff 0, #fff 46%, transparent 50%, transparent),
    radial-gradient(circle at center, #fff 0, #fff 46%, transparent 50%, transparent),
    radial-gradient(circle at center, #fff 0, #fff 46%, transparent 50%, transparent),
    radial-gradient(circle at center, #fff 0, #fff 46%, transparent 50%, transparent),
    linear-gradient(to right, #EBA146, #E17233);
  background-position:
    5px 5px,
    calc(100% - 5px) 5px,
    5px calc(100% - 5px),
    calc(100% - 5px) calc(100% - 5px),
    0 0;
  background-size:
    12px 12px,
    12px 12px,
    12px 12px,
    12px 12px,
    100% 100%;
}

Чтобы быстро вникнуть надо нормально знать php.*
И тогда можно использовать что угодно.

* кроме битрикса, туда вникнуть нельзя никак даже теоретически, там полная каша.

Так и должно быть. Номера потворно никогда не используются. Вот вы mr-labsder решили отправить деньги мне, а я взял и удалился из системы, или админ меня удалил, у меня был номер 16. Так деньги никому не придут и вернутся вам, т.к. id 16 не существует теперь, а в противном случае на id 16 стал бы другой участник и деньги попали к нему бы и все думали бы что всё нормально, так и надо.

Или другой пример. У вас есть ИНН 12 цифр, вот представьте себе что кто-то умер (во всём государстве), и что у вас теперь ИНН должен уменьшится на 1? Так он так 1000 раз в день бы менялся ))))

Высокопроизводительные распределенные интернет-приложения. Конкретные примеры: amazon.com, netflix.com, ebay.com. NoSQL движение возникло как ответ на проблемы масштабируемости. Реляционные базы ориентируются на требования ACID и как следствие имеют проблемы с горизонтальным масштабированием. Для таких баз необходимо реализовывать шардинг на уровне приложения. Но тогда будет необходимо отказаться от ACID, объединения таблиц и контроля целостности. В таком случае реляционная база теряет все козыри перед NoSQL. Но оставляет на плечах разработчика заботу о шардинге.

Интернет забит вопросами о том как жить без транзакций в NoSQL. Но бизнес-процессы в реальной жизни не являются транзакционными. Вы не можете человека, который покушал в вашем ресторане, а теперь отказывается платить по счетам заставить сделать роллбек вашей еды. Фактически посетитель вам бросил эксепшен. И даже если вам удастся извлечь еду из вашего посетителя, то маловероятно, что она будет готова к последующему употреблению. Но можно взыскать с него все затраты через суд и придти таким образом в согласованное состояние. Любому бизнесмену это очевидно. Но программисту нет. Он хочет транзакционно. Но пишет систему для автоматизации бизнес-процессов. Парадокс.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.