Форум: "Базы";
Текущий архив: 2002.10.07;
Скачать: [xml.tar.bz2];
ВнизНа что сменить ГЛЮЧНЫЙ Paradox? Найти похожие ветки
← →
3JIA9I CyKA (2002-09-12 16:34) [40]Борман уже сам признался в нестабильности рагадоха.
И как-то очень легко верится.
← →
Anatoly Podgoretsky (2002-09-12 16:37) [41]Engel (12.09.02 16:31)
Local Share=True этого достаточно
← →
Mike Kouzmine (2002-09-12 16:40) [42]3JIA9I CyKA ©, по всей видимости, в комсомоле никогда не состоял(а), а то бы знал(а), что настоящие комсомольцы, как продолжатели дела коммунистов, ни кому не должны верить, тем более на слово, да еще хоть и известному, но немецко-фашистскому захватчику.
← →
3JIA9I CyKA (2002-09-12 16:47) [43]2Mike Kouzmine (12.09.02 16:40)
Нехорошо советовать людям дикий гемор.
Не лучше давать советы по его (гемора) одомашниванию.
← →
Engel (2002-09-12 16:48) [44]Для Anatoly Podgoretsky:
А вообще можно где-то прочитать про принцип работы dbase в сети? То есть, если строка занята одним пользователем, что в этом случае происходит? Или все обращения на sql-запросы переводить?
И еще - как оформить обновление данных на экране?
Простите за ламерство, но нигде найти не могу.
← →
Mike Kouzmine (2002-09-12 16:53) [45]Я шучу. Разговор не по делу. Надо в потрепаться. Каждый день одно и тоже. Пошел домой.
← →
GoldMedium (2002-09-12 18:34) [46]По поводу InterBase. Может кто подскажет, каким образом можно уменьшить размер базы данных на IB.
50 метров базы за 600000 записей - многовато (с учетом того, что данные абсолютно не упаковываются).
← →
Val (2002-09-12 18:43) [47]в одной ветке обо всем? :))
>GoldMedium (12.09.02 18:34)
с учетом того, что данные абсолютно не упаковываются
это означает, что backup/restore не помогает, или что?
← →
MsGuns (2002-09-12 20:30) [48]>GoldMedium (12.09.02 18:34)
>50 метров базы за 600000 записей - многовато (с учетом того, что данные абсолютно не упаковываются).
Не специалист именно в IB, но по опыту скажу, что само по себе кол-во записей НИКОГДА не определяет физ.характеристики БД. Записи бывают разные: от 2 полей в таблице до 200, да и сами поля могут быть от SMALLINT до memo или graph.
Точно знаю одно: использование в качестве связующих ключей или индексов полей длинною более 20 символов (а я видел "шедевры", где ключи были по 255 и даже 1024 символа) ведет к РЕЗКОМУ увеличению размеров и снижению быстродействия БД
← →
evgeg (2002-09-12 20:39) [49]> Вот. Потом IB ИБан#$ся... с IB уже имел опыт столкнуться... не справляется он с БД более 100 метров и 3-5 пользователей, и всё... уже так ресурсы сервера жрёт :(, и тормозит как камаз %
Полная чушь.
← →
Alex Marmuzevich (2002-09-12 21:16) [50]Занющим посвящается:
1. Я рекомендовал не MSSQL а MySQL, так как
- абсолютно бесплатно
- легко работает
- типы данных практически соответствуют Paradox,
- хорошо работает через ODBC
- есть свободные компоненты, по функциональности идентичные TTable
2. Замену на MSSQL не рекомендую, так как погано таблицы работают при добавлении. Кроме того, сомнения берут в бесплатности. + Бесплатна однозначно однопользовательская версия
3. В свое время мне очень нравилось восстанавливать Paradox таблицы, случайно погибшие потому, что пользователь просто перегружал компьютер нажав на Reset вместо того, чтобы сделать это по правилам.
4. Я лично видал интереснейший глюк Access (до 2000), который откровенно валился при попытке добавить еще одну запись и вс5е из-за того, что размер базы был 30М. Правда с этой базой пытались работать несколько клиентов одновременно.
5. FireBird - хорошо, но уж слишком бедный выбор базовых типов данных по сравнению с Paradox. Особенно меня смущала в свое время отсутствие автоинкрементных полей (хотя проблема и решалась триггерами с генераторами). + FireBird родственник InterBase, которая то стала свободной, то снова закрылась. Это меня тоже настораживает.
← →
evgeg (2002-09-12 21:37) [51]> отсутствие автоинкрементных полей (хотя проблема и решалась триггерами с генераторами).
Тригер+генератор гораздо лучше автоинкрементного поля.
← →
Виталий Панасенко (2002-09-13 09:02) [52]>evgeg © (12.09.02 21:37)
> отсутствие автоинкрементных полей (хотя проблема и решалась >триггерами с генераторами).
>Тригер+генератор гораздо лучше автоинкрементного поля.
автоинкремент проще обьявить и использу, а тут нужно еще и триггер рисовать, хотя мне нравится и то, и это
← →
Val (2002-09-13 10:28) [53]>Виталий Панасенко (13.09.02 09:02)
зато значением генератора можно оперировать.
← →
Polevi (2002-09-13 10:45) [54]>Alex Marmuzevich (12.09.02 21:16)
У меня есть база Access - 70 метров с ней работают 30 человек и представьте себе только тем и занимаются что добавляют записи. И ничего никуда не валиться. Если сделано криво будет валиться на чем угодно.
← →
KSergey (2002-09-13 11:16) [55]
> 2. Замену на MSSQL не рекомендую, так как погано таблицы
> работают при добавлении.
Погано - это как?!! Может я что-то не так делаю? Может я записи не так добавляю? О чем речь?!
← →
ShooRoop (2002-09-13 12:00) [56]MSSQL - идеальная субда, у меня база полтора гига, порядка 40 активно работающих с ней пользователей, живет 2 года без ЕДИНОГО глюка. Стоит своих денег, 100/16.
← →
Alex Marmuzevich (2002-09-14 16:04) [57]>Погано - это как?!! Может я что-то не так делаю? Может я записи >не так добавляю? О чем речь?!
Сделай форму TTable + TDataSource + TDBGrid.
Открой таблицу с автоинкрементным полем. Добавь строку, свведи данные и сохрани. Без Refresh в виде Close->Open будет очень интересно таблица отображаться.
Если повторить аналогичную процедуру с Paradox таблицей - все отлично
← →
Polevi (2002-09-14 17:17) [58]>Alex Marmuzevich (14.09.02 16:04)
вы в суд на майкрософт подадите, они вам денег заплатят за моральный ущерб
← →
evgeg (2002-09-14 23:30) [59]> Alex Marmuzevich (14.09.02 16:04)
TTable вообще не надо использовать для баз Client/Server.
← →
Hro (2002-09-15 00:40) [60]Я вообще не пойму, что трудно TTabe заменить на TQuery с Select * from Table1 ?
← →
Peter Gluhiy (2002-09-15 17:21) [61]> evgeg © (14.09.02 23:30)
TTable к базам Client/Server обращается через SQL-запросы!
Или вы думаете что напрямую к файлу БД?
← →
Mike13 (2002-09-16 00:06) [62]а никто тут Visual FoxPro не пробовал? работает с данными побыстрее любого Access"a
← →
Anatoly Podgoretsky (2002-09-16 00:27) [63]Так Visual FoxPro или дельфи с Visual FoxPro таблицами
← →
int64 (2002-09-16 04:19) [64]Моё имхо, любую серьёзную базу сразу писать как клиент/сервер; ресурсы нынешних компьютеров это позволяют. Даже если она всегда будет локальной.
По крайней мере, это меньше извращение, чем из локальной лепить сетевую. (Постоянно вижу такое чудо из FoxPro).
← →
Alex Marmuzevich (2002-09-16 11:16) [65]Почему собственно "TTable вообще не надо использовать для баз Client/Server". Я как-то не читал у Borland ограничений. Да и по-моему, уж лучше TTable, чем RequestLive = true. Кроме того, для ODBC баз что TTable, что TQuery используют единый механизм доступа к данным.
← →
Romkin (2002-09-16 12:08) [66]Ну да... попробуйте открыть таблицу записей эдак 10000 в TTable & TQuery, и посмотрите разницу. TTable всегда пытается тянуть индексы, да и автоматическая работа с запросами просто на высоте, иногда вполне может перечитывать всю таблицу после правки одной записи. Так что только TQuery - для сервера, TTable - для файловой базы
Вообще-то действительно, лучше сразу client/server, чтобы потом не переделывать, я сам давно уже отказался от локальных таблиц
Страницы: 1 2 вся ветка
Форум: "Базы";
Текущий архив: 2002.10.07;
Скачать: [xml.tar.bz2];
Память: 0.57 MB
Время: 0.01 c