Владимир Чернышев

Чисто в теории можете попробовать slight - никакой установки.

Если «Мд5 строить все равно придется», он будет заведомо уникальным (то есть логика не допускает добавления двух картинок с одним хэшем), то почему нет (при условии что индексы и основной, и связанных таблиц будут помещаться в памяти, если важно быстродействие). В любом случае, насколько я понимаю, хэш будет считаться только при попытке добавления картинки в базу, а количество выборок по ид будет много больше числа таких попыток.

Вот только я бы посоветовал хорошо подумать, а действительно ли вам нужна уникальность хэша, не может ли это требование потом измениться. Или, скажем, решите сменить алгоритм хэша — изменение отдельного уникального поля куда менее дешевая операция, чем изменение основного ключа и всех индексов связанных таблиц.

Плюс, если я правильно понял идею (что-то вроде фотохостинга, хэш картинки используется для урлов) могут быть интересные ситуации типа: один пользователь добавил картинку, получил её новый урл, потом второй добавил её же, система засекла дубликат и выдала уже существующий хэш. Затем первый пользователь удалил картинку, система засекла, что есть ещё ссылки и удалила только ссылку из альбомов первого пользователя, не удаляя саму картинку — в итоге первый пользователь может увидеть, что несмотря на удаление картинка осталась доступна по старому урлу. Кому-то может всё равно, а кто-то может поднять крик про личные данные и т. п.

Почему-то все отвечающие акцентировали внимание на выбор между разными, но очень похожими SQL РСУБД. NoSQL вполне себе достойная альтернатива, особенно если подавляющее большинство выборок либо являются выборками по одной таблице со словарями, либо сложными выборками, нацеленными на обеспечение гибкой схемы сущностей (задаваемые пользователями атрибуты и т. п.).

Вроде как Drupal из коробки поддерживает версионирование нод.

Если вам точно нужен статический язык, но не си/плюсы, то посмотрите в сторону Java/С#.

Под name использовать 25 в случае utf-8 имхо не самая лучшая идея, даже если ограничиться русским, на мыло 50 тоже может не хватить в извращенных случаях, но соответствующих rfc (домены.рф например :) ). Да и вообще никакого оверхеда между varchar(1) и varchar(256) нет, смысла экономить не вижу, если в требованиях есть ограничения, то проверять их в приложении и именно на количество символов, а не байт (для php — mb_strlen(), а не strlen() ).

Довольно много полезного про NoSQL (при применении в вебе вообще, и в django в частности) есть вот здесь allbuttonspressed.com/

ru.wikipedia.org/wiki/%D0%A1%D0%A3%D0%91%D0%94

Если абстрагироваться от таких «мелочей» как производительность, масштабируемость и надёжность, то Д(окументно)О(ориентированные)СУБД и О(объектно)О(ориентированные)СУБД во многих случаях позволяют разработчику отражать сущности предметной области на сущности БД без введения дополнительных сущностей :), которые приходится вводить в Р(еляционных)СУБД. Например, сколько копий переломано в спорах о том, как хранить в РСУБД объекты различных классов, унаследованных от одного базового класса (в одной таблице с кучей пустых полей, в таблицах для каждого отдельного класса, в общей таблице общие поля, ...), а тут просто храним в одной «таблице» и не думаем о таких мелочах. Отношения 1:1 и 1: М, когда сущности во второй половине отношения принадлежат одной и только одной сущности первой и не имеют смысла без неё также отображаются без дополнительных таблиц и полей для связи (вместо comments.post_id и comments.content просто храним в поле posts.comments список/массив комментов, не заботясь о целостности связей, синхронизации и т. п.). Другими словами, ДОСУБД часто облегчают жизнь разработчику, хотя иногда её усложняют (когда связи двунаправленные прежде всего, особенно M: М — для установления связи между двумя уже существующими сущностями надо производить две операции — добавление к первой ссылку на вторую, а ко второй на первую -, а не одну — добавление в таблицу связи — как в РСУБД )