Оно не годится никуда вообще. Это выхолощенный академический пример. Если нужна права доступа, удаление, версионирование, локализация - хранятся индентификаторы, сами файлы с метаданными в отдельной таблице.
Если вы считаете, что подвергать резервному копированию 100 Гб базу с картинками внутри, вместо 1 Гб данных + инкрементальный бэкап статических файлов через rsync, то мне вас жаль, правда.
Ну и напоследок, раскажите мне, как вы с вашими картинками будете организовывать кластер базы данных, таская туда сюда эти картинки.
Какой смысл в плагине для браузера, специально написанном софте, если большинство нормальных принтеров поддерживают подключение по сети и поднимают на себе TCP/IP сервер? Со своего сервера цепляетесь к принтеру и пишете туда все, что душе угодно. А печать из браузера осуществляется вызовом какого-нибудь JSON RPC на сервере.
Ограничение на документ 16 Мб в целом, со всеми коллекциями.
Вот, например, специальности я бы вынес в отдельную коллекцию - потому что они между факультетами помуг пересекаться.
Здрасьте вам, что значит "не имеет"? Метод ожидает первым параметром объект, реализующий интерфейс FormContractorInterface. Дадите другой - выкинет ошибку.
Какой фуллскан? SELECT objects.* FROM tag_object LEFT JOIN objects ON tag_object.id = objects.id WHERE tag=:tag
То, что тег в tag_object стоит проиндексировать, упоминать, я думаю, не стоит?
Ну потому что это язык со сборкой мусора какой-никакой, нельзя точно на 100% сказать, когда будет вызван деструктор. Порядок выполнения деструкторов тоже не гарантируется.
Вобщем непредсказуемая немного вещь, и это не только мое мнение.
Ничего подобного.
В конфигурации gitolite прописываются права доступа к репозиториям, где имя пользователя это название файла с публичным ключом, хранящимся в gitolite.
Когда вы подключаетесь к репозиторию, используется ваш приватный ключ по-умолчанию (id_rsa). gitolite на той стороне ищет соответствующий публичный ключ, и если его находит, то авторизует под пользователем, имя которого задано названием этого публичного ключа. Имя пользователя в системе, с которой вы ломитесь в git, и название файла ключа могут не совпадать.
@Valenso, в клонировании через JSON единственная проблема, которая может волновать, это производительность. Но мне почему-то кажется, это не та проблема, которая вас сейчас должна волновать :)
Пишите как вам удобней - оптимизировать успеете всегда.
Открываете подходящий по знаниям проект, смотрите issues, которые открыты, форкаете, исправляете, делаете pull-реквест разработчику. Если ему понравится ваш код, он возьмет ваш коммит в свой репозиторий. После чего в ленте вашей публичной активности будет отображено, что вы внесли исправления в тот или иной проект. Штук 50 таких исправлений, и это уже весомый аргумент при встрече с потенциальным работодателем.
Но для начала нужно гит подучить, да.
Если вы считаете, что подвергать резервному копированию 100 Гб базу с картинками внутри, вместо 1 Гб данных + инкрементальный бэкап статических файлов через rsync, то мне вас жаль, правда.
Ну и напоследок, раскажите мне, как вы с вашими картинками будете организовывать кластер базы данных, таская туда сюда эти картинки.