Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Нужна консультация косательно сервера БД [D7, Win2k]

Страницы: 1 2 >
NiGGa © (2005-10-11 20:09:00)
Доброго времени суток.
Что такое SQL и концепции построения БД я знаю довольно хорошо, на теоритическом уровне. Таблички рисовал, нормализацией занимался и советы давал, но вот самому до данного момента, на практике заниматся не приходилось. Но вот, по объективным причинам пришлось.

Это присказка. Теперь сказка. Нужны рекомендации по реализации. Есть выбор MySQL и MSSQL, что выбрать? И соответственно какими средствами лучше работать? Желательно личные соображения и послать туда где есть примеры. Т.к. чтение ТД меня очень утомляет, длительный процес знаете ли, а вот хороший пример посмотреть, это совсем другое.

И последнее. Мне нужно хранить видеоархив. Правильный ли подход хранить кадры в блобах в БД и в последствии(одна из основных функций, что должны присутствовать = это просмотр видеоархива, с разными скоростями) доставать? Потому как мне кажется, что идея хранить это на винте и через сокет-конекшн передавать клиенту,не совсем умно.

Всем заранее спасибо.

NiGGa (2005-10-15 19:15:00) [1]
2 0bsid
Почему же, вы почти все правильно поняли. Исключение составляет тот момент, что каждая камера "присоеденена" к отдельному хосту, т.к. задача не видеонаблюдения на самом деле, но некоторыми пунктами схожа.

Впрочем некоторое решение уже найдено и по сути вопрос можно считать закрытым, всем внесшим конструктив - спасибо.

0bsid (2005-10-14 23:25:00) [2]
как я понял, ты делаешь систему видеонаблюдения с 8 камер с частотой записи 1 кадр/сек? если так, то:

можно записывать в один кортеж сразу 8 кадров со всех камер чтобы не тягать сервак туда-сюда по таблице
думаю эстетичность просмотра не особа важна, тогда с помощью обычного TTimer делай показ следующего кадра из базы данных, чтобы ускорить уменьшь интервал, и наоборот
для такой задачи и MySQL должно вполне хватить

если я не прав и запись 8 видео потоков в сети 100мбит будет вестись с частой 25-30fps, то легче приобрести специальное оборудование для этого

NiGGa (2005-10-14 17:23:00) [3]
Да и сетка должна быть нехилая для такой работы...

:) Класическая 100МБит - это нехилая или еще нет?

Курдль (2005-10-14 16:58:00) [4]

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

В принципе - почему бы нет. Но дать совет, не попробовав... Так что придется лабораторную работу проводить самому. С другой стороны - хорошие СУБД при работе с большими наборами данных гарантируют высокую общую производительноть, а не "время выборки кадра". Поэтому придется позаботиться о сильной буферизации на клиенте. Да и сетка должна быть нехилая для такой работы...

NiGGa (2005-10-14 16:50:00) [5]
Начну отвечать с конца, уж извините.
2 Курдль
Никто не указывал на то, что компонент типа TImage присутствует.

2 ANB
Кодеков то куча, но тогда клиенты, те которых 6-, должны еще заниматся сжатием видеопотока, на самом деле у них и так задач хватает.

Многие фильмы и так на CD не влазят, я это уже давно заметил, буквально с появлением DVD.

Межкадровое сжатие используется, теми кому оно нужно. Но это не есть стандарт.

2 DSKalugin
Спасиба. Действительно никто не собирался на каждый кадр делать по запросу.

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

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

Курдль (2005-10-14 14:41:00) [6]

> экспериментировать надо

Не надо :-(
Сразу скажу - средствами Delphi, даже без обращения к БД а просто "отображать карды в обычном TImage" и получить кино НЕ ПОЛУСИТСЯ :-(

ANB (2005-10-14 14:40:00) [7]

> DSKalugin © (14.10.05 14:33) [20]

Все ИМХО.
MySQL не пробовал, но оракл не вытянет такой нагрузки. Особливо в многопользовательском режиме. Надо искать способ сжатия для уменьшения трафика. А степень сжатия полного ролика выше, плюс есть куча готовых кодеков.

DSKalugin (2005-10-14 14:33:00) [8]
Если хранить кадры, а не полные ролики в блобах, то самым важным требованием к СУБД будет скорость выборки. MySQL - самый быстрый читатель, с ним только Oracle может потягаться в скорости

> Как "натравить" средство просмотра видеоролика на BLOB поле?
> Через OLE Container? Через потоки? Или сначала выгружать
> в файл?

Есть идейка пложить на форму TTimer в обработчике которого шуровать селекты по определенному временному интервалу(это в к вопросу скорости воспроизведения) и отображать карды в обычном TImage. Синхронно или асинхронно показывать с использованием буффера это уже практика покажет, экспериментировать надо

ANB (2005-10-14 10:57:00) [9]
Мона еще много винчестеров наставить на сервак.

Курдль (2005-10-14 10:52:00) [10]

> msguns © (14.10.05 10:46) [16]

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

msguns (2005-10-14 10:48:00) [11]
Пардон, вместо слова "проект" в самом первом предложении следует читать "архив"

msguns (2005-10-14 10:46:00) [12]
Приходится по долгу "службы" иногда общаться с областным радио. У них свой (правда звуковой), но весьма обширный проект. Все хранится в МП3 (старые записи архива с кассет оцифровываются, "эмпэшатся" и переносятся на "болванки". Есть "сервер", куда можно ставить сразу до 8 CD (8 приводов), доступный в сети.
Есть программка, которая имеет БД, где записана инфа о названии, дате, № CD и названии файла мп3. Если нажать соотв. "конпульку", то прога лезет на "сервер" и дает запрос на нужный сидюк. Висящая на "сервере" простенькая прога - "сервер" принимает запрос и "оглядывает" имеющиеся активные девайсы. Если нужного диска нет, то выдается соотв. требование для установки на один из свободных девайсов (указывается тут же) сиди с нужным номером. Девочка - оператор быстренько находит сидюк (в номере диска присутствует стеллаж, полка, ряд и №).
"Сервер" сначала копирует содержимое диска на жесткий диск (типа кэша), а потом просто возвращает "клиенту" полный путь к этому файлу.

Сам видел - работает довольно шустро и безотказно. Надежность достаточно высокая. Правда требуется определенная дисциплина и аккуратность от персонала. Но, учитывая простоту работы оператора, проблем здесь не было. Справлялись даже выпускницы школ после неделной стажировки.

Курдль (2005-10-14 10:40:00) [13]

> ANB © (14.10.05 10:33) [14]
> Почти во всех системах видеосжатия межкадровка используется.
> Сжатие кадра по принципу JPEG дает слишком мало эффекта.
> Тогда бы фильмы на CD не влезали.

Вот статья, которая противоречит вышесказанному: http://www.videomax.ru/tests/dvd403/

ANB (2005-10-14 10:33:00) [14]

> Курдль © (14.10.05 10:30) [13]

Почти во всех системах видеосжатия межкадровка используется. Сжатие кадра по принципу JPEG дает слишком мало эффекта. Тогда бы фильмы на CD не влезали.

Курдль (2005-10-14 10:30:00) [15]

> ANB © (14.10.05 10:20) [12]
> Плюс все сжатие - коту под хвост.

Я не особо интересовался системами сжатия, но сейчас есть, как я понял, 2 основные - DV и DVD. В первой, кажись, сжатие именно покадровое. А во второй - уже межкадрово корелляционное (это я только что придумал :)

ANB (2005-10-14 10:20:00) [16]

> NiGGa © (13.10.05 18:25) [8]
Кадры по отдельности ? Одуреть. Тогда готовьте сервак покруче и на скорость больше 5 кадров в секунду тут расчитывать нечего. Плюс все сжатие - коту под хвост.

Курдль (2005-10-14 09:58:00) [17]

> NiGGa © (13.10.05 18:25) [8]
> А почему 700 мегов? Или по вашему хранить каждый кадр в
> отдельной записи не правильно, тогда почему?

Я не совсем понял, Вы хотите сделать собственый инструмент для просмотра, монтажа и хранения видеоальбомов? Хранить ролики покадрово в БД и надеяться, что кадры будут приходить от СУБД со скоростью ~30 к/с? И с такой же скоростью отображаться средствами Delphi?

NiGGa (2005-10-13 18:26:00) [18]
Удалено модератором

NiGGa (2005-10-13 18:25:00) [19]
Удалено модератором

NiGGa (2005-10-13 18:25:00) [20]
2 Курдль
А почему 700 мегов? Или по вашему хранить каждый кадр в отдельной записи не правильно, тогда почему? Также если хранить видеоархив большими кусками видео возникает вопрос эффективности, т.к. пользователь в принципе может запросить видеоархивчик с любого по любое время(любое в смысле - заданное пользователем).
И что значит натравить средство просмотра? В первых какое средство просмотра? Во вторых почему в блобе сразу же видеоролик лежит?

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »