Жуткая база

Eyellow
Дата: 11.07.2012 10:12:28
Здравствуйте, коллеги. Я довольно давно занимаюсь БД 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 (если такое существует)?
WildSery
Дата: 11.07.2012 11:07:32
Eyellow,

Думаю, виновата программа-моделлер, и разработчик, который оставил по умолчанию "неограниченная длина" для строк.
kdv
Дата: 11.07.2012 11:08:59
Eyellow
Вы видите? ВСЕ строки в BLOB!

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

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

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

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

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

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

Если тебя не просят это поддерживать - так и хорошо.
А вот если просят, то плохо.
Ivan_Pisarevsky
Дата: 11.07.2012 13:48:30
kdv
наименьший общий делитель
фраза понравилась.
всегда единица, как ни крути. :)
Если я еще совсем курс арифметики начальной школы не забыл.
oleg_m
Дата: 11.07.2012 14:17:18
kdv
Eyellow
Вы видите? ВСЕ строки в BLOB!

напугал. в PHPBB версии 2, если не ошибаюсь, когда они все переводили в юникод


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

P.S. а есть ли у нас тикет на расширение границ VARCHAR ?
32K деленное на 4 - слишком мало, увы.
WildSery
Дата: 11.07.2012 14:44:45
oleg_m,

Предлагаешь размыть границы между VARCHAR() и BLOB SUB_TYPE TEXT?
oleg_m
Дата: 11.07.2012 15:23:43
WildSery, в общем - да.
Кому будет нужен BLOB SUB_TYPE TEXT, если varchar сможет принимать, скажем 2Гб.
dimitr
Дата: 11.07.2012 15:27:35
oleg_m
Кому будет нужен BLOB SUB_TYPE TEXT, если varchar сможет принимать, скажем 2Гб.

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