Димон Дурак

Если бд имеет поддержку json, то общие поля сделать полями таблицы, а добавочную часть положить в виде json в ещё одно поле таблицы.

Когда ты копируешь картинку, в буфер она попадает в формате base64:

document.onpaste = function(event){
  var items = (event.clipboardData || event.originalEvent.clipboardData).items;
  console.log(JSON.stringify(items)); // will give you the mime types
  for (index in items) {
    var item = items[index];
    if (item.kind === 'file') {
      var blob = item.getAsFile();
      var reader = new FileReader();
      reader.onload = function(event){
        console.log(event.target.result)}; // data url!
      reader.readAsDataURL(blob);
    }
  }
}

Вот еще рабочий вариант: jsfiddle.net/bt7BU/225

1. Никаких «вечных серверов». Даже как-то неловко разъяснять такое. «Вечный сервер» — маркетинговый ход, фактически мошенничество, который закончится, как только компания изменит условия/реорганизуется/закроется. Следует читать как «ну, проработает года три, а далее — неизвестно».

2. Непонятно, какого рода у вас информация, и что именно вы понимаете под словом «захостить», также непонятен критерий автономности. Разместить информацию в публичный доступ? Должна ли она индексироваться? Нужен ли для неё контроль доступа? По какому протоколу она должна быть доступна? Она будет нужна только вам через 10 лет, или кому-то еще? Это лицензированный контент, который могут удалить по DMCA (фильмы, сериалы, музыка)? Это персональные данные (сливы баз данных)? Информация популярна и/или востребована на данный момент? Есть вероятность, что она будет сравнительно востребована через 10 лет? Информация каталогизирована? Информация тематическая (например, архив, посвященный конкретной теме, области науки и т.п.)? Важно ли удобство и скорость доступа к информации?
Технологий много, но они все разные, с разными назначениями. Ответы на перечисленные вопросы необходимы, чтобы отбросить неподходящие и подробно рассмотреть подходящие.

3. Если информация публична и востребована, и будет востребована через 10 лет, то следует использовать DC++, BitTorrent + веб-хранилища с прямыми ссылками на файл, добавив ссылки в .torrent-файл, в виде webseed.
Bittorrent существует с 2006 года, популярен, клиенты есть под все ОС, совместимость и надёжность отличные.
DC++ всё еще имеет популярность. Основное преимущество перед Bittorrent: возможность поиска файла по его имени или названию директории, возможность лёгкого обновления и дополнения информации (нет привязки к «каталогу» в виде .torrent-файла)

Если информация конфиденциальна или требует контроля доступа, и у вас и кого-либо другого не будет возможности как-либо поддерживать её в течение 10 лет (я не знаю вашу ситуацию, поэтому предположим, что вам грозит 10-летний тюремный срок), то, возможно, есть смысл оплатить облачное хранилище от крупных компаний (Google, Yandex, Microsoft, Apple) на 10 лет вперед. Это не даёт никаких гарантий, но считаю такой вариант более надёжным, нежели хостинг общего плана (и особенно VPS).

Если информации немного, она не защищена авторскими правами, каталогизирована и полезна, можно банально разместить её на давно существующих бесплатных хостингах, вроде Ucoz, Google Sites, Neocities, загрузить на Bitbucket, Github, Sourceforge (последний поддерживает хранение больших файлов, которые можно скачать по прямой ссылке, вполне подойдёт в качестве webseed для торрента, к слову).

Если не боитесь попробовать развивающиеся, но еще не устоявшиеся технологии, присмотритесь к IPFS. Он работает по принципу Bittorrent, но позволяет получать доступ к информации через HTTP, а также поддерживается крупными игроками в лице Cloudflare, у которой есть шлюз из интернета в IPFS: https://cloudflare-ipfs.com/
Я держу несколько статичных сайтов с собственными доменами в IPFS, на домашнем компьютере, за шлюзом Cloudflare. Преимущества: все плюсы BitTorrent, возможность доступа как к сайту (в т.ч. на своём домене), индексация поисковиками, есть сервисы по долгосрочному платному хранению файлов (eternum.io, pinata.cloud), возможность лёгкого обновления информации. Недостатки: работает всё ещё достаточно медленно и нестабильно, только статичные сайты.

4. Судя по вашему комментарию выше, у вас всего 100 ГБ медиафайлов. Это вообще ерунда. Если они публичны и представляют ценность хотя бы для узкого круга людей, можете захостить их у меня, через проект Schare: https://valdikss.org.ru/schare/
Мой критерий автономности — максимальная независимость от сторонней инфраструктуры, поэтому файлы хостятся на домашнем сервере, а раздаются в сетях децентрализованного файлообмена.

Вариант "просто разложить по папкам" не подходит когда музыки более 10Gb.

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

Обо всем по порядку

Дескрипторы - так понимаю речь идет о дескрипторах свойств объекта. Вещь крайне полезная, позволяющая задать поведение свойству, сделав его не перечисляемым или, например, только для чтения, а так же можно задать функции getter/setter, которые будут вызываться при чтении/записи свойства. Используется довольно часто.

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

bind - по сути является декоратором встроенным в язык. Позволяет привязать к функции контекст и начальные аргументы. Используется постоянно, особенно в случае передачи функции во внешний код.

call и apply позволяют вызвать функцию с нужным контекстом, разница в том что apply принимает 2 аргумента - контекст и массиво-подобный объект содержащий аргументы, а call принимает произвольное число аргументов: 1й - контекст, последующие передаются как аргументы функции. Используется постоянно.

Карринг. Хоть и используется не так часто, но бывает весьма полезным инструментом. По сути цепочки промисов построены на принципах карринга, только не функций, а объектов.

Ну и напоследок, конструкция var self = this; позволяющая сохранить контекст в замыкании уже потихоньку уходит в прошлое, благодаря стрелочным функциям из es2015

Почитайте «Теорию игр и принятие решений», поймёте, почему идеальной системы голосования не существует. Всё зависит от того, как считать.

Также стоит ознакомиться:
Как правильно сортировать контент на основе оценок...
Механизм расчета рейтинга магазина на Яндекс.Маркет
Формула расчета рейтинга на кинопоиске

Посмотрите в сторону NodeJS. Это серверный JS, сейчас применяется достаточно активно, но пока не понятно на сколько перспективен.

Никогда не пробовал, но знаю, что во многих игровых движках можно писать на нем. Например unity и cocos2d. Но не уверен требуются ли разработчики такого плана.

Попробуйте посмотреть вакансии по ключевому слову, это поможет найти другие применения.