Какую СУБД выбрать?

← →
WondeRu © (2004-03-18 09:53) [0]

Есть следующие задачи, которая должна обслуживать БД:
1. Клиентские рабочие места - 20-30
2. До 400 транзакций в сек.
3. Отказоустойчивось
4. Триггеры, библиотеки расширения и т.п.
5. Недорогая
6. Windows/Linux

Что подскажите? Какую СУБД выбрать?

← →
Vlad © (2004-03-18 09:55) [1]

Оракл, если денег не жалко :-)

← →
WondeRu © (2004-03-18 10:05) [2]

Oracle - отпадает. Больно уж дорог, да и его мощности многовато на 30 клиентов. Бессмысленная трата денег.

← →
Vlad © (2004-03-18 10:09) [3]

InterBase после 6 версии или FireBird

← →
Zacho © (2004-03-18 10:16) [4]

> Vlad © (18.03.04 10:09) [3]

Присоеденяюсь. Только насчет 400 тр./сек не уверен, в моей практике было поменьше. Но кто мешает автору топика поставить FB 1.5 и проверить ? По остальным требованиям подходит, особенно по цене :)

← →
WondeRu © (2004-03-18 10:24) [5]

Сейчас Fb и стоит, но охота проверить с другими и получить большее быстродействие + при аварийном выключении (а иногда просто) сервака порой база портится.

← →
Vlad © (2004-03-18 10:29) [6]

> WondeRu © (18.03.04 10:24) [5]

Выбирай на любой вкус :-)
http://www.dbforums.com/
Там же можно и консультацию получить по интересующим вопросам.

← →
Romkin © (2004-03-18 10:31) [7]

[5] Forced Writes включи, не должна БД просто так портиться

← →
Zacho © (2004-03-18 10:35) [8]

> при аварийном выключении (а иногда просто) сервака порой
> база портится.

Поставь UPS на сервер. Или см. http://www.ibase.ru/v6/ib6faq.htm#fwoff

← →
WondeRu © (2004-03-18 10:52) [9]

Если я не ошибаюсь, то Forced Write = ON уменьшит скорость работы. Или я не прав?

← →
Romkin © (2004-03-18 10:57) [10]

А ты проверь :)) Сейчас практически разницы быть не должно, особенно на Linux
В любом случае, это лучше, чем крах БД

← →
WondeRu © (2004-03-18 11:03) [11]

А у нас оказывается включен FW! А все равно бывает слетает база

← →
serge35 (2004-03-18 11:08) [12]

Проверь, может еще что лишнее включено?

А недорогая - это в пределах какой суммы?
На рынке за 80 р можно любую купить.
Правда Oracle 9 по-моему на двух дисках,
поэтому он и дороже в 2 раза.

← →
WondeRu © (2004-03-18 11:12) [13]

>serge35 (18.03.04 11:08) [12]

Если бы система не ставилась на гос и т.п. объекты, то я бы этот вопрос не задавал!)))

>На рынке за 80 р можно любую купить.
Знаю где по 35р. в Самаре ;-)

← →
Romkin © (2004-03-18 11:16) [14]

[11] Странно, причем весьма. Мне так и не удалось обрушить БД при FW. Модет быть, что-то с аппаратной частью?

← →
Vlad © (2004-03-18 11:19) [15]

> Romkin © (18.03.04 11:16) [14]

> Мне так и не удалось обрушить БД при FW

Как рушил ? :-)

← →
WondeRu © (2004-03-18 11:21) [16]

>Как рушил ? :-)

Заполняешь базу всякой фигней, и выдераешь вилку компа из розетки)

← →
Vlad © (2004-03-18 11:24) [17]

> WondeRu © (18.03.04 11:21) [16]

Странно, так просто рушиться не должна...

← →
Romkin © (2004-03-18 11:24) [18]

Vlad © (18.03.04 11:19) [15] НУ как? ЗАпускаются 10-15 потоков, в каждом - цикл работы с БД. На автозагрузке...
НУ и reset стоишь, жмешь периодически. Как еще?

← →
Vlad © (2004-03-18 11:28) [19]

> Romkin © (18.03.04 11:24) [18]

Мне удавалось обрушить в момент Restore - вырубаешь комп, потом включаешь и файл бэкапа и самой БД порушен :-)

← →
Zacho © (2004-03-18 11:30) [20]

Я тоже примерно так эксперементировал лет 5 назад. Базу порушить не удалось. Так что похоже у WondeRu © проблемы с железом. Но в таком случае никакой другой SQL-сервер не поможет.

← →
WondeRu © (2004-03-19 08:26) [21]

>Zacho © (18.03.04 11:30) [20]
Это-то проблемы с железом на фирменных IBM, HP и др.?)))

УПС предположим стоит, но давайте на вопрос попробуем ответить: какую СУБД выбрать для увеличения скорости по сравнению с FB? Работат 30 компов, на каждом запущено до 16 потоков работы с БД (16*30=480 потоков), и все это добро должно иметь как можно меньшее время отклика!

← →
bushmen © (2004-03-19 10:27) [22]

>какую СУБД выбрать для увеличения скорости по сравнению с FB?
Попробуй Cache

← →
Romkin © (2004-03-19 10:28) [23]

Yaffil, NSSQL, Oracle
Меньшее время? Более мощный сервер, и оптимизировать запросы

← →
Romkin © (2004-03-19 10:29) [24]

А операционка какая? На Linux FB заметно быстрее работает, чем на NT
Zacho © (18.03.04 11:30) [20] Скорее, кстати, похоже на проблемы с ОС :))

← →
Romkin © (2004-03-19 10:29) [25]

← →
Delirium © (2004-03-19 10:33) [26]

Для Windows - однозначно MSSQL, если база < 2Gb, то - бесплатный (DeskTop Edition).

← →
bushmen © (2004-03-19 10:43) [27]

>6. Windows/Linux

MSSQL отпадает по условию задачи

← →
Delirium © (2004-03-19 10:45) [28]

Тогда, без сомнения - InterBase, как уже предлагалось, лучше ничего не придумаешь.

← →
serge35 (2004-03-19 10:56) [29]

Сервер надо купить в 10 раз мощнее.
И не надо экономить деньги организации, на которую
ты работаешь. Если они хотят 400 транзакций в сек.
то пусть раскошеливаются на сервак за 20-40 тыс $.
И сетевое оборудование.
А если для организации УПС купить проблема,
то пусть берут счеты и на них работают.

← →
WondeRu © (2004-03-22 08:54) [30]

>то пусть раскошеливаются на сервак за 20-40 тыс $.

Если ПО стоит $3000-4000, то вообще нереально отдельный сервак выделять!

← →
roottim (2004-03-22 09:29) [31]

>Oracle - отпадает. Больно уж дорог, да и его мощности многовато на 30 клиентов. Бессмысленная трата денег

интересно где-же он будет дорог... 300 баков за намед юзера..
у тебя их всего 30-40.. то биш около 10 кусков он тебе обойдется

40000$ на анлимиед - это может и дороговато... но если у тебя будет более 1000 юзеров.. лучше сервера сейчас думаю не найти...

во вторых при твоем требовании на 400 тразакций в сек... это тоже оптимальный вариант..
в отличие о других субд работа блокировок и транзакций в оракле сделаны оптимально (быстро, удобно, без потерь)

в третьих.. не такой оракул и прожорливый... еже-ли правильно настроить (у нас тестовый инстанс на персоналке XP п3 с 256м озу и то работает кул), ну конечно по занимаемым ресурса с FB не сравнить... но нужно понимать что назначение их разное.. и гарантии и возможности тоже...

← →
Sergey13 © (2004-03-22 09:49) [32]

2roottim (22.03.04 09:29) [31]
40000$ - это на процессор в энтерпрайс эдишн. Стандарт - 15000$, Стандарт Он - 5995$. Я читал где то, что Ораклы собираются снизить цену на стандарт он до 4000 и разрешить там работать на 2 процах+урезаная репликация.
Так что дороговизна Оракл - это не совсем так.

← →
roottim (2004-03-22 10:10) [33]

2Sergey13 © (22.03.04 09:49) [32]

про все цены я в курсе...

> Так что дороговизна Оракл - это не совсем так

и полность с тобой согласен...

если взять к примеру комерческую лицензию мускула ~ 500$ за намед узера, то незнаю что и выбрать... я бы не сомневался в пользу оракула...

про Cache не могу ничего сказать... сам потихоньку его осваиваю.. но уж очень все у меня медленно... слишком "большой" опыт в РЕЛЯЦИОННЫХ СУБД... трудно мозги перестраивать.
но когда я делал запрос к ним.. як бы купить...
то ценник был 300 с соплями на юзера... то биш по цене сопоставим с оракулом.. а вот в во всем остальном трудно сказать.. хоть они и заявляют о своей "быстр, умен, не требует сильного админа"... но реальных сравнений (не те хвалы что на их сайте) я не видел...

← →
snake1977 (2004-03-22 10:12) [34]

а Oracle 7 можно бесплатно юзать :)
потому как ен снят с производства

← →
Sergey13 © (2004-03-22 10:17) [35]

2snake1977 (22.03.04 10:12) [34]
Можно даже 10Г. Но не в промышленной эксплуатации. 8-)

2roottim (22.03.04 10:10) [33]
Да я собственно не для тебя и писал. Просто цифру ты назвал, на тебя и сослался. Сори. Я догадываюсь что ты знаешь. 8-)

← →
WondeRu © (2004-03-22 10:23) [36]

А где можно накопать сводный прайс всех распространенных в России СУБД?

← →
Sergey13 © (2004-03-22 10:24) [37]

2WondeRu © (19.03.04 08:26) [21]
>Работат 30 компов, на каждом запущено до 16 потоков работы с БД (16*30=480 потоков)
А что за работа такая, что именно 16 потоков? Что вообще 400 транзакций делают? Они ведь есть разные, эти транзакции. Если даже Оракла поставить и им никак не заниматься, то ИМХО и ему тяжеловато будет. Загубить можно все что угодно.

← →
WondeRu © (2004-03-22 10:29) [38]

>Sergey13 © (22.03.04 10:24) [37]
на каждом компе может висеть до 16 железяк на портах, которые должны управляться и мониториться в реальном времени и записывать свои события в ОДНУ БД!

← →
roottim (2004-03-22 10:37) [39]

2Sergey13 © (22.03.04 10:17) [35]
да я разве обиделся ?... просто ежели пишеш 2roottim то все что ниже предназначеается мне.. .. а я тебе и сказал что что "знаю про них"

2WondeRu © (22.03.04 10:29) [38]
речь идет о постоении (точнее наверно имитации, так-ка тут и операционка и СУБД все должно быть завязано.. и вребя обработок критично) систем реального времени, то оракул 100% тебе в помощь...

← →
WondeRu © (2004-03-22 10:43) [40]

Насчет Оракла ВЫ меня почти убедили, а насчет сводного прайса не подскажите? Где накопать? Плюс, виды лицензий на каждую СУБД! Ищу, не могу найти ничего подходящего((

← →
Sergey13 © (2004-03-22 10:44) [41]

2WondeRu © (22.03.04 10:29) [38]
А что они делают, железяки эти? Инсертят или апдейтят? Если индексов много - могут тормозить. В общем фиг его знает. Если основная работа только на вставку, то Оракл может и не ускорит. Пробовать надо, однако. Аппарат однозначно ускорит, особенно дисковая подсистема. ИМХО.

← →
roottim (2004-03-22 10:45) [42]

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

← →
WondeRu © (2004-03-22 10:52) [43]

Лана, я буду толкать Оракл! Всем, принявшим участие, огромное спасибо!

← →
Sergey13 © (2004-03-22 11:01) [44]

2WondeRu © (22.03.04 10:52) [43]
Толкать можно. Но хочу тебя предупредить, что это несколько отличается от ИБ и с ходу после инсталяции, без опыта и обучения, тебе будет ох как не просто.

← →
roottim (2004-03-22 11:40) [45]

рекомендация... Благо наконец вышла в свет книга Тома Кайта "ORACLE для крутых перцев" ( шутка.. но смысл в том же :)) ) точнее уже 2-х томник.. для понимания этой СУБД она будет тебе очень и ОЧЕНЬ полезна...
ЗЫ
у меня есть все книги издательства ЛОРИ по 8и -ке..
но по опыто все вопросы (и ответы) я всегда черпал именно от Кайта (ну кроме маналов) на его сайте asktom.oracle.com или его книг

← →
Deniz © (2004-03-22 12:12) [46]

Off
> roottim (22.03.04 10:10) [33]
> про Cache не могу ничего сказать... сам потихоньку его осваиваю.. но уж очень все у меня медленно... слишком "большой" опыт в РЕЛЯЦИОННЫХ СУБД... трудно мозги перестраивать.
А как, пардон, Вы с этим чудом работаете? Т.е. среда(Delphi/C++ и т.д.), способ доступа?

← →
Petr V. Abramov © (2004-03-22 12:57) [47]

> 1. Клиентские рабочие места - 20-30
> 2. До 400 транзакций в сек.
Это по 20 тр/сек с рабочего места. Если 1 тр = 50 байт, то это ~70М/час, при работе даже по 8 час/день 80 Гиг винта хватит на 15 дней максимум. По сами, понимаете, ну чересчур оптимистичной методике подсчета. Может, это все же какие-нить данные с датчиков, и СУБД тут не надо использовать (по крайней мере, сразу сырые данные в нее гнать)?

← →
roottim (2004-03-22 13:25) [48]

2Deniz © (22.03.04 12:12) [46]
изучаю как и все прочее... в делфи я сораклом работаю..
а Caсhe пока на стадии их подручных средств CSP, Studio, Тирминалка, и скл менеджер..
- под делфи можно использовать одбс или com объекты
но все-же их основной упор на CSP .. т.к веб-сервис интегрирован всместе с их ядром.. и думаю интерфейсы делфи здесь необходимы постольку поскольку... например отчетик в фаст-репортере забабахать.. ну или малоли что бывает. так что в этом контексте и работаю.. :)) надеюсь удовлетворено любопытство !

← →
roottim (2004-03-22 13:28) [49]

2Petr V. Abramov © (22.03.04 12:57) [47]
это тоже вариант... формировать файлы с опр. структурой и писать значения напрямую туда... а затем переносить (если конечно есть перерыв во времени снятий данных..
в этом случае любая удобная для обработки результатов база подойдет.. ну а если напрямую туда... то наверно всеже оракул

← →
Petr V. Abramov © (2004-03-22 13:36) [50]

> roottim (22.03.04 13:28) [49]
> .. ну а если напрямую туда... то наверно всеже оракул
Угу. И писатели биллинговых систем тут же не выдержат конкуренции и разорятся :) Да такие системы (400 транзакций в секунду), наверное, по пальцам пересчитать можно. Или автор не ведает, что творит, или не ведает, за что взялся, или это не транзакции :)

← →
roottim (2004-03-22 13:57) [51]

2Petr V. Abramov © (22.03.04 13:36) [50]
да я думаю что не так все грустно...
он привел пиковую нагрузку.. 16 устроиств на клиента
а реально-то думаю меньше... и данные "думаю" снимаются не милисекундами...
- хотя ситуация когда все устр-ва одновременно будут писать в базу возможна... только все зависит от минимального времени транзакции... Оракле сдесь имеет плюс в том что одновременная вставка в таблицу не вызовет колизий... наверно и все...

- ну а если и правда с такой мощностью идет наполнение... то всетаки необходимо испытать и то и то... и сравнить результаты..
т.е при записи в файл и работа напрямую с субд.

← →
Petr V. Abramov © (2004-03-22 17:20) [52]

> roottim (22.03.04 13:57) [51]
Спор на пиво, что в файл быстрее? :)
Если, конечно, не совсем кривыми руками :)
> он привел пиковую нагрузку..
Да если даже на 10 поделить, все равно не кисло.
Но соглашусь, что если уж так решит человек писать сразу в базу,то лучше в Oracle :)

← →
WondeRu © (2004-03-23 09:03) [53]

Люди, железяки же не осциллографы, это был самый худший вариант 30х16! А так в час тройку сотен событий от устройства придет уже радость))) Но пиковая нагрузка должна присутствовать на крайний случай, все-таки же почти технологический процесс, т.е. самый край задержки 5 сек.!

← →
Sergey13 © (2004-03-23 09:39) [54]

30*16*300=144000 событий в час=40событий в секунду
тоже не слабо, если я ничего не напутал.
Что за событие, скока чего пишется? Зачем нужны результаты? Как часто и по каким критериям инфа читается из базы? Написал бы нормально про задачу. А то гадание на кофейной гуще какое то.

От механического перехода на Оракл на старой машине я бы не ждал автоматического ощутимого прироста надежности/скорости. Можно даже замедление получить. На тупой вставке в таблицу трудно что то выиграть. В Оракле можно много чего подкручивать, но не скорость записи на диск.

← →
roottim (2004-03-23 10:04) [55]

2Sergey13 © (23.03.04 09:39) [54]
> В Оракле можно много чего подкручивать, но не скорость записи на диск
собственно причем тут запись на диск... это бд а не операционка..
для чего буферный кэш тогда существует..
а насчет того что настроить можно так что время записи будет много более времени поступления - это можно... но это уже не только оракле относится а ко всему семейству БД.
> Что за событие, скока чего пишется
это да.. хотелось бы услышать оценочные параметры..
2 WondeRu © (23.03.04 09:03) [53]
>т.е. самый край задержки 5 сек
это означает что задержка в записи=5сек - максимальный предел?
если так... то запись напрямую подходит для этого случая точно

← →
WondeRu © (2004-03-23 10:04) [56]

машины хоть пеньки 3ГГц, ет не проблема! Но FB устарел как класс СУБД! Поэтому и есть нужда перейти к чему-нибудь более совершенному! А 40 событий в секунду - вероятность такого исхода порядка 0.5%! События записываются простыми инсертами, но при этом параллельно действует логика, которая реагирует на событие и также обращается к базе для анализа предыдущих событий!

← →
roottim (2004-03-23 10:16) [57]

2WondeRu © (23.03.04 10:04) [56]
тогда флаг в руки... даже 40 соб в секунду - это нормально при правильной всавке (подготовить план запроса.. свзываемые переменные и в путь...) если при вставке логика проверок минимальна - то средствами пл/скл пишем процедурку вставки и оставляем ее в разделяемом пуле (keep), для скорости. если логика проверки данных более "мощная" - то вставке данных ничего не должно мешать.. а выявление ошибок в данных производить в фоновым процессом или мулькой...

← →
Sergey13 © (2004-03-23 10:19) [58]

2roottim (23.03.04 10:04) [55]
Если в БД идет постоянная запись, то при чем тут буферный кеш? Про чтение из БД автор упорно ничего не сообщает. Наверное это тайна покрытая мраком. 8-)

2WondeRu © (23.03.04 10:04) [56]
А по конкретнее можно? Ты все про секунды да про события. А что за события, что за объемы - ни слова. Например - что есть "анализ предыдущих событий"? Агрегатные значения за месяц? Да при таких объемах что угодно в ступор встанет.

ЗЫ:
И не надо про устаревшее как класс СУБД!
Разруха она в головах. (с) пр.Преображенский.

← →
roottim (2004-03-23 10:28) [59]

2Sergey13 © (23.03.04 10:19) [58]
> Если в БД идет постоянная запись
перенаправляю..
> А так в час тройку сотен событий от устройства придет уже радость

такчто думаю скорость записи на диск будет не критична при достаточном размере буф.кэша (на пиковую нагрузку)

← →
Sergey13 © (2004-03-23 10:36) [60]

2roottim (23.03.04 10:28) [59]
Так три сотни в час от одного устройства. От 30*16 устройств это 40 в секунду. А это немало. Так это еще без "анализа предыдущих событий"!
Или я запутался в цифирях?

← →
roottim (2004-03-23 10:39) [61]

еще разз...
>уже радость
вероятно
>А 40 событий в секунду - вероятность такого исхода порядка 0.5%

>От 30*16 устройств это 40 в секунду. А это немало
у меня по 100 в секунду бывает(редко.. но проверял) вставок в базу... все ничего...

>Sergey13 c (23.03.04 10:19) [58]
Про разруху в головах, а в частности всяких там Швондеров и Шариковых (а возможно и у меня) мне известно!

Короче анализировать нужно (уже делается) последние 5-10 событий всех устройств!
События: срабатывание контактного датчика, обрыв провода и т.п.

2roottim (23.03.04 10:39) [61]
Ну у автора все очень противоречиво. Вначале было 400 транзакций в секунду, потом вероятность 40 в секунду стала 0.5%... Как он это все считает с точностью до полупроцента? 8-)

>у меня по 100 в секунду бывает
У меня и больше бывает, но кратковременно, слава богу. 8-)

>Sergey13 © (23.03.04 10:48) [63]
Могу написать 0.5099% ;-) Сам не считал, но вероятность какая-то все же присутствует! Аудитом такой хр.. (вероятностей) я еще не занимался!

2WondeRu © (23.03.04 10:46) [62]
А по какому принципу ты отбираешь "5-10 последних по всем", если от устр №1 последнее было 3 дня назад, а от устр №444 полсекунды назад. И как записывается это событие? код.устр./дата.время/величина?

2WondeRu © (23.03.04 11:15) [66]
Интересная у тебя задача.
Кто то чего то делает с какой то вероятностью, но уверенности нет ни в чем. Хотя цифры приводишь на удивление конкретные, хотя и не нужные, в основном. После этого говоришь FB отстой, а Оракл (который в глаза не видел) рулез форэва. 8-) Даже не интересно продолжать.

> FB отстой, а Оракл (который в глаза не видел) рулез форэва.
>

Так и есть

>Sergey13 © (23.03.04 11:25) [67]
Oracle-то я ставил, но чисто в образовательных целях.

>Self "не я этим занимаюсь"
именно анализом не я, а представление обо всей системе вполне конкретное и ... кушать уже охота... )))

Про "Трёп" согласен. FB нельзя сравнивать с Oracle. Хорошо ещё, что модераторы это терпят 8)

Тут еще надо учитывать, что основная загрузка - это, как я понимаю, всавка данных в БД.

MSSQL и Oracle. 8)

Ну это точно в треп. 8-)

Я бы начал от другого плясать: чем обернется то, что 40 событий в сек. не успеют отработаться вовремя? А 400? Если это крах всей системы с милионными убытками и гибелью сотен человек или это 5 минут вмешательства оператора?
Если первое - то на это и надо действительно закладываться, верноятно - винда тут не канает.
А если второе - то давайте все же говорить о реальной нагрузке с разумным запасом.
А то сейчас выяснится, что 97% нагрузка будет один инсерт в 5 сек и одна выборка 5 строк по ключу в 30 сек, а расет будет на жуткого монстра с жуткой ценой...

← →
яч (2004-03-23 16:19) [78]

> 1. Клиентские рабочие места - 20-30
> 2. До 400 транзакций в сек.
а не устанут 30 человек делать 400 транзакций в сек???

> Fay © (23.03.04 11:43) [72]
> FB нельзя сравнивать с Oracle.

Можно. Ибо версионность в Оракле растет именно из IB. Но разговоры на эту тему уж точно надо в "Потрепаться" :)

Нет! "Ибо версионность в Оракле растет именно из IB" - жемчужина "Орешника".

Еще не в трепе? Странно!!! 8-)

>KSergey © (23.03.04 14:22) [77]
>Если это крах всей системы с милионными убытками и гибелью сотен человек или это 5 минут вмешательства оператора?

К первому ближе!

2WondeRu © (24.03.04 08:20) [82]
>К первому ближе!
Ну тогда давай трепаться. 8-)
(недавно помнится ядерные эксперименты на БД ставили, теперь опять люди в опасности 8-).

С какой частотой "центр" запрашивает статистику по всем приборам? Раз в секунду? минуту? 5 минут? час? Если ближе к последнему, то может стоит передавать туда инфу уже предварительно обработаную на клиенте с чуть меньшей периодичностью. Если исходить из того что прибор все таки должен работать нормально, зачем уведомлять об этом центр? Может достаточно послать отчетик типа период/среднее/макс.отклонение. А вот при возникновении "нештатной" ситуации слать сразу и подробно?
На клиентских машинах сидят операторы? Если да, то наверное и уведомлять в первую очередь надо их, а не "центр". Т.е. может над общей логикой работы подумать. (люблю я это дело 8-)

> [82] WondeRu © (24.03.04 08:20)
> >KSergey © (23.03.04 14:22) [77]
> >Если это крах всей системы с милионными убытками и гибелью
> сотен человек или это 5 минут вмешательства оператора?
>
> К первому ближе!

Нифига себе!
И в этом случае вы берете на себя смелость ее проектировать, получая ответы в публичных форумах?
Вы уж извините, но может не ваша это задача, а?

2KSergey © (24.03.04 09:28) [85]
Думаю, все таки смысл есть, не указывается же сама система и ее прямое назначение. Щас схожу на лабы по "Системам дистанционного зондирования Земли" и приду продолжить диспут!

KSergey © (24.03.04 09:28) [85]
Может задача и его, но вот его рукодство уже сейчас можно сажать на большой срок, не дожидаясь последствий, а если это не сделать сейчас, то надо сажать руководство этого руководства.

Какую СУБД выбрать? Найти похожие ветки