Проектирование БД

[Deimos]

Доброго времени, уважаемым коллегам.

Не то, чтоб прямо совет нужен... Просто хочу услышать размышления... По этому и в потрепаться...

Сабж: БД (SQL) в которой будет куча инфы. База резюме. Будет спонтанное кол-во картинок у каждого соискателя. Возможно видео.

Кто из вас как-бы спроектировал такое-вот чудо?

Я знаю и про блобы и про все такое ) И работать с базами тоже умею ) Просто интересно послушать мнения... И для потомков полезно будет, да и мы может что новое для себя ухватим...

Если не по нраву кому - прошу извинить...

[olegy123]

я за блобы.. удобно когда логика программы совмещена с данными. интеграция с другими продуктами без боли будет.

Добавлено спустя 3 минуты 37 секунд:

Кто из вас как-бы спроектировал такое-вот чудо?

Ууу, это просто потрепаться или желание увидит всю готовую работу?

[Deimos]

Ууу, это просто потрепаться или желание увидит всю готовую работу?

Я понимаю, как это выглядит, но нет... (Я заранее извинился за это). Я правда могу спроектировать это сам. Мне интересен брейншторм, если он получится. И новые, возможно, упущенные мной, идеи.

З.ы. Я написал именно в "потрепаться".
З.ы.1 Если появится на форуме ветка брейншторм, то я был бы рад, и, по возможности (свободном времени, желании) принимал бы участие
З.ы.2 Это не дипломный проект. Мне правда интересны мнения тех, кто пишет не так, как я...

[Снег Север]

Решение сильно зависит от оценок размера файлов. Если несколько мегабайт, то можно хранить в блобах. Если десятки и выше - в файловой системе, а в базе - пути.

[Mirage]

Сильно зависит от того, как будет использоваться.
Хотя картинки и тем более видео я бы в базе не хранил. Для этого есть более эффективные хранилища. В базе ссылка только.

[Vadim]

Делал аналогичную штуку, называется БД "Патенты". Именно из-за того, что "патенты", все картинки хранятся в базе. Картинки, описание изобретения и реферат - в блобах. В обязательном порядке полнотекстный индекс, иначе будет долгий поиск по контексту. Хотя, если не предполагается полей с чем-то типа, как например в литинституте при приёме на учёбу требуется предоставить рассказ, стихи или перевод, то полнотекстовый индекс не нужен.

[java73]

Делал аналогичную штуку, называется БД "Патенты". Именно из-за того, что "патенты", все картинки хранятся в базе. Картинки, описание изобретения и реферат - в блобах. В обязательном порядке полнотекстный индекс, иначе будет долгий поиск по контексту. Хотя, если не предполагается полей с чем-то типа, как например в литинституте при приёме на учёбу требуется предоставить рассказ, стихи или перевод, то полнотекстовый индекс не нужен.

Надеюсь, не для гражданина Квасенкова делали сие чудо)))

[wadman]

Я-бы завел отдельное хранилище для файлов, которое имеет апи. И на выходе, к примеру, выдает id/guid файла, который-бы и хранился в базе.

[serbod]

Если база данных может работать как портативная (на флешке) и хранится в одном файле (плюс необязательные файлы - индексы, журнал, блокировки) - то лучше картинки держать в блобах. Проще будет копировать.

В любом случае, все картинки в отдельной таблице, так будет проще перейти на папку с файлами (или обратно), если возникнет необходимость. И ссылаться по уникальному идентификатору (GUID), а не по имени файла, при этом текстовое представление GUID в качестве имени файла вполне годится.

Видео в БД держать не стОит никак, просто потому, что из БД его не получится воспроизвести, а из файла - запросто, хоть локально, хоть через сеть.

[debi12345]

SQLITE3...SQLITE3...SQLITE3...

[olegy123]

Если несколько мегабайт, то можно хранить в блобах. Если десятки и выше - в файловой системе, а в базе - пути.

а если блоб ограничен размером в 1Тб?
можно узнать сколько можно, а сколько уже не надо..

Добавлено спустя 6 минут 15 секунд:

Видео в БД держать не стОит никак, просто потому, что из БД его не получится воспроизвести, а из файла - запросто, хоть локально, хоть через сеть.

все можно, главное обеспечить битрейт..
если посмотреть на контейнеры(avi,mkv,mpeg4..) это упаковщики фреймов,кадров,звуковых сэмплов. та же БД с ключевым полем времени или кадром. Никто не запрещает иметь свой упаковщик.

Добавлено спустя 4 минуты 46 секунд:

SQLITE3...SQLITE3...SQLITE3...

PostgreSQL!!!

[Deimos]

SQLITE3...SQLITE3...SQLITE3...

Мысль понятен, но он не подходит. Операторов 2+

PostgreSQL!!!

Никогда не использовал(обычно Maria). Просмотрел инфу по верхам. Почему так категорично? Действительно на столько стабильней, как обещают?

[Mirage]

Действительно на столько стабильней

Что значит стабильней? Стабильней чего?
Просто работает. Нулов в not null полях не держит, DML в транзакциях умеет.

[Vadim]

Надеюсь, не для гражданина Квасенкова...

Сия фамилия мне неизвестна...

[zoltanleo]

а если блоб ограничен размером в 1Тб?

это ж сколько будет занимать база только с одним терабайтным блобом? И сколько после бекапа? А если бекапов несколько? Это ж никакого железа не хватит...