Миша, есть phpMyAdmin - через него проще, чем совсем руками, если исходные данные - не в отдельном файле.

Хотя IMHO в твоём случае, когда исходная инфа есть вся кучей, в разных видах, лучше сначала вручную/ножную/непонятно-какую вбить всё это локально в один или несколько файлов в формате дампа базы и потом эти файлы одной командой импортнуть в базу.
Ладно, завтра обсудим...

это FireBird реальный? не, только Oracle и DB2! тебя назначаем спонсором.

Угу, а вот на базах размером 2-3 миллиона записей начинаются косяки, сам наблюдал и боролся.


В пятом мускуле тоже появились триггера:
http://dev.mysql.com/doc/refman/5.1/en/triggers.html
Правда как они работают - не проверял.


Кстати напоминаю что FB это опенсорсная реализация IB Ты работал с FireBird? А я вот работал и довольно долго. И уж лучше mysql, а еще лучше postgres, но упаси боже от FireBird. Он не выдерживает никакой критики по производительности, транзакции реализованы так, что с ними невозможно работать (никто не дает никаких гарантий что данные, модифицированные или добавленные в текущей транзакции, после commit-а попадут в базу в полном обьеме). Хотя да, триггера и хранимые процедуры есть и работают без особых претензий.

На тему Oracle: гы, вы собрались гвозди микроскопом забивать?

Имхо для БЗ подойдет любая СУБД, ибо обьемы мизерные, и запросы несложные.

У меня в самой большой таблице 42 млн записей и все работает очень шустро.


Долго - это пол-года?
Я с БД работаю уже 19 лет, а программирую 33 года,
поэтому никогда не высказываю категорических мнений о программных средствах. База базе рознь, да и программисты всякие бывают
Каждое программное средство найдет свою нишу.

Ага, и очень плотно. Вплоть до того что сорцы ковырял.


Не смеши! mysql - это веб онли с минимум изменений базы. postgres был академически задуман хорошо, но реализация... Короче сейчас он скорее мёртв чем жив.


Прозводительность - прямое следствие кривизны рук. Без правильной планоровки запросов и индексов ни один сервак работать быстро не будет.


Нифига себе!!! С транзакциями так как раз ситуация на порядок лучше чем чем в mysql . По функционалу почти как в Оракле. Например в MSSQL в одном коннекте можно работать только с одной транзакцией, а в FB - с любым количеством. И кстати, я не в курсе есть ли наконец то в mysql уровень изоляции snapshot?


Гнусный поклёп !!! С надёжностью там всё хорошо. Commit реально просто меняет один бит статуса транзакции.

Для FB наработано огромное количество инструментария.

Инструментарий-то фигня. Лучше шли, что вбивать, куда и какие данные и какой объём. Набъём/поможем - я как раз в отпуске буду две недели, по вечерам помучаю. Сэкспортить можно всё из всего, в этом проблемы нет. А то обсуждение Ора-кала и инкапсуляции транзакций не ближе к решению проблемы, чем кольца Юпитера.

Только кинь вначале базу, я хоть гляну - а то потом мучаться не хочется. Верю в твой опыт, но всё же...

Прочёл флейм — по сути ноль, всё круто, а данные набивать некому.
:–)
Тока Вольфрамыч если.

Я типа не согласная? Я хочу только на базню вначале взглянуть. Кампи не мычит не телится - что/как/куда/сколько?

Вон ещё Zuzzuk есть. Прорвёмся

Я не про "шустро".
Например такой косяк (не единственный, просто самый яркий и очевидный): есть таблица a с полем some_field уник. В таблице b тоже есть поле some_field, тоже уник. В таблице a порядка 800 тысяч записей, не очень то много. Таблица b пустая. Делаем запрос по типу
INSERT INTO b SELECT FROM a. Получаем ругань на duplicate key. Полчаса имеем геморр, решается все просто. Знаешь как? "/etc/init.d/mysqld restart" - и запрос выполняется как надо и без единой ошибки. Это что, нормальное поведение СУБД? Стабильная работа? Напоминает "have trouble in windows - reboot ". Хорошо хоть сервер свой на колокейшне, а иначе что делать? На хостинге никто не даст рестартануть mysqld.

Год. И пиписьками мерятся не надо. Лучше скажи чем же firebird лучше того же mysql пятого или postgres?

Определенно у тебя длиннее, не спорю.

Никто не спорит, но зачем создавать себе же трудности, если есть более стабильные и производительные программные средства?

Ты типо согласная, тока пока ты отправляла, я по кнопкам ещё колотила.

Да я вначале на структуру хотело взглянуть, в самом начале. Могу бить, могу не бить...

Моё первое вопросо было:



И оно подразумевало условное согласие. Вот.

Дима не переживай , откликнулось три человека тут и два в привате, у нас столько данных нет

Для Марка и других интересующихся http://www.balticstar.spb.ru/file06/Protocols-02.rar
232 кил

Всем , кто откликнулся, спасибо огромное, сегодня посижу и определюсь кому, что. Вчера не получилось, обсуждали с Федором красочный календарь-2006.

Вполне мило. Единственный совет - у...ть к чертям русские имена полей. Нэ совэтую. Детально структуру не посмотрел, но выглядит прилично.

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

а экспортнуть во что-нибудь нормальное структуру можешь? а то нет у меня ни аксесса, ни виндов чтоб его поставить.

О, дельно.
Hцrman, как же как же, помню-помню.