Жуткая база

Здравствуйте, коллеги. Я довольно давно занимаюсь БД Firebird, но то, что увидел вчера, я не видел никогда вообще.
Дело вот в чём. У нас внедрена довольно известная в узких кругах система. Клиент в браузере, есть сервер приложений и backend в виде базы. В новой версии этой системы разработчики использовали ORM Hibernate. Система написана на дотнете 4, кроме FB поддерживает MS SQL, а также заявлена поддержка Oracle. Не смотрел в другие базы, но то, что я увидел в FB повергло меня в шок.
Всё, больше не буду распинаться, просто приведу DDL.

CREATE TABLE "User" (
    ID                      BIGINT NOT NULL,
    UID                     CHAR(16) CHARACTER SET OCTETS,
    STATUS                  INTEGER,
    USERNAME                VARCHAR(255),
    "Password"              BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    FIRSTNAME               BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    MIDDLENAME              BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    LASTNAME                BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    FULLNAME                BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    EMAIL                   BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    BIRTHDATE               TIMESTAMP,
    EMPLOYDATE              TIMESTAMP,
    WORKPHONE               BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    MOBILEPHONE             BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    ROOMNUMBER              BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    DESCRIPTION             BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    LANGUAGE                BIGINT,
    SKYPE                   BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    ICQ                     BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    JABBERID                BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    AUTHPROVIDERGUID        CHAR(16) CHARACTER SET OCTETS,
    REPLACEMENTUSER         BIGINT,
    DUPLICATEMESSAGE        SMALLINT,
    ENDREPLACEMENT          TIMESTAMP,
    REPLACEMENTMODE         INTEGER,
    REPLACEMENT             BIGINT,
    ORGANIZATIONGROUPSHASH  BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    ORGANIZATIONITEMSHASH   BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    PHOTO                   BLOB SUB_TYPE 1 SEGMENT SIZE 80
);

CREATE TABLE CURRENCY (
    ID         BIGINT NOT NULL,
    UID        CHAR(16) CHARACTER SET OCTETS,
    NAME       BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    SHORTNAME  BLOB SUB_TYPE 1 SEGMENT SIZE 80
);

Вы видите? ВСЕ строки в BLOB! В таблицах, обслуживающих интерфейс (пункты меню и т.п.) тоже все строки в BLOB. Система в процессе работы создаёт таблички. Так там тоже все строковые значения хранятся в BLOB. Вообще во всей базе. На данный момент там 302 таблицы...
Я, честно говоря, никогда не имел дело ни с Hibernate в частности, ни с ORM вообще. Я хочу понять: кто виноват? Кто так спроектировал? Разработчики нашей системы? Разработчики ORM Hibernate? Разработчики драйвера Firebird для Hibernate (если такое существует)?

Eyellow,

Думаю, виновата программа-моделлер, и разработчик, который оставил по умолчанию "неограниченная длина" для строк.

Eyellow
Вы видите? ВСЕ строки в BLOB!

напугал. в PHPBB версии 2, если не ошибаюсь, когда они все переводили в юникод, в MySQL база из таблиц со строками превратилась в таблицы с блобами. Так что там ты бы даже этих char и varchar не увидел :-)

Eyellow
Я хочу понять: кто виноват? Кто так спроектировал?

скорее всего Hibernate. Это же универсальная хрень, типа BDE. Вот ее разработчики и не заморачиваются с поддержкой разных типов данных в разных СУБД. Херакнул блоб, и готово.
Ну и с запросами у них то же самое - наименьший общий делитель, со всеми вытекающими.

А не по фиг ли, господа, как оно там спроектировано?

Пока "известную в узких кругах" используют только эти самые узкие круги - оно нафиг ни кому не надо, ибо у этих самых узких кругов объем данных не критичен и можно вот так издеваться.

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

А пока всех все устраивает, - бесполезно разжигать холивар.
Первое правило сисадмина: "работает? - ничего не трогай!".

Eyellow,

Если тебя не просят это поддерживать - так и хорошо.
А вот если просят, то плохо.

kdv
наименьший общий делитель

фраза понравилась.
всегда единица, как ни крути. :)
Если я еще совсем курс арифметики начальной школы не забыл.

kdv
Eyellow Вы видите? ВСЕ строки в BLOB! напугал. в PHPBB версии 2, если не ошибаюсь, когда они все переводили в юникод

Eyellow, неплохая идея!
надо будет попробовать.

P.S. а есть ли у нас тикет на расширение границ VARCHAR ?
32K деленное на 4 - слишком мало, увы.

oleg_m,

Предлагаешь размыть границы между VARCHAR() и BLOB SUB_TYPE TEXT?

WildSery, в общем - да.
Кому будет нужен BLOB SUB_TYPE TEXT, если varchar сможет принимать, скажем 2Гб.

oleg_m
Кому будет нужен BLOB SUB_TYPE TEXT, если varchar сможет принимать, скажем 2Гб.

дык он храниться все равно будет как блоб. Так нафига тогда?