Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: опять про выбор БД (аналоги аксесса)  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Модератор

На SQL.ruпринято обращение на ВЫ

Поправлюсь, раз так просите, но в правилах про обращение на "ВЫ" ни слова. Зато ясно прописано про оскорбления (это про пост 1024)
Правила форума на SQL.RU (v1.0)
Содержание сообщений
Запрещается:
публикация грубых, оскорбляющих и унижающих сообщений.
17 июл 06, 23:40    [2891189]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
Я всего лишь назвал вещи своими именами
18 июл 06, 09:48    [2891809]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
1024
Я всего лишь назвал вещи своими именами

Оставь свои имена себе
18 июл 06, 11:36    [2892705]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
да ладно, пусть и другие посмотрят
18 июл 06, 12:05    [2892961]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Pantalone
Member

Откуда:
Сообщений: 1326
Может хватит цирк устраивать? Задрали. Детский сад, е-мое, взрослые люди...
22 июл 06, 17:02    [2913967]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Pantalone
Member

Откуда:
Сообщений: 1326
EloyOrion
SQL Server 2005 EveryWhere Edition
http://www.microsoft.com/sql/ctp_sqleverywhere.mspx

Если чем-то Express Edition не устраивает, то встраивайте в своё приложение EveryWhere Edition.


Мне вот интересно эта штука, она из под VB6 как будет видиться? Или же она только под .NET?
Хорошо бы если не только из под .NET и желательно как mdb одним файлом, скопировал и работай спокойно.
22 июл 06, 17:03    [2913970]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
это сервер. Доступ через jdbc, odbc, oledb из любой программы (жаба, нет, вин32). Но как .мдб не будет, это ж сервер
2 авг 06, 10:49    [2954103]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
1024
автор
Как будто базы на Access ставятся простым копированием и сначала сам Access устанавливать не надо


аксесная база .mdb а клиент на ц-диез. Значит сам аксес не нужен

Значит нужен NET.FrameWork. Его тоже ставить надо. И, я не знаю точно, но вроде поддержка Jet в FrameWork по умолчанию не входит.
Точно знаю, что на "голую" машину для работы с mdb надо jet ставить. Причем, она теперь в MDAC не входит и надо ставить отдельно.
5 авг 06, 19:02    [2969453]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Cat2
Точно знаю, что на "голую" машину для работы с mdb надо jet ставить.

Да-да, конечно.
Cat2, ты, возможно, будешь удивлен, но на голую машину сначала надо ставить винду. А винда в себе уже содержит jet (если это не триодиннадцатая винда, конечно). Jet, разумеется, надоть сервиспачить, но сервис-паки на джет частенько включаются в сервис-паки для опять-таки винды.
Так что что ты там "точно знаешь", и кто тебе такую чушь наплел - прям загадка какая-то...
6 авг 06, 02:19    [2970077]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Пьяный Лох

Так что что ты там "точно знаешь", и кто тебе такую чушь наплел - прям загадка какая-то...

Ну, лично сам себе наплел.
Никакого джета винда не ставит. Другое дело, что почти всегда сразу и офис ставится, который по умолчанию ставит джет. Однако можно и запретить его ставить. Если не жамкать на установке по умолчанию.
6 авг 06, 11:15    [2970207]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
8)

всё что надо для работы с виндой ставится само.

одни прафисиналы кругом. Лучшая замена аксеса - аксес. От добра добра не ищёт, дурная голова ногам покая не даёт и т.д.
6 авг 06, 22:51    [2970810]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Cat2
Пьяный Лох

Так что что ты там "точно знаешь", и кто тебе такую чушь наплел - прям загадка какая-то...

Ну, лично сам себе наплел.

Ты лично сам себя обманул.
За это можешь лично сам себя убить ап стену.
7 авг 06, 00:02    [2970869]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Pantalone
Member

Откуда:
Сообщений: 1326
1024
8)

всё что надо для работы с виндой ставится само.

одни прафисиналы кругом. Лучшая замена аксеса - аксес. От добра добра не ищёт, дурная голова ногам покая не даёт и т.д.

При больших обхемах он далеко не лучший. Места кушает в несколько раз больше других вариантов, того же FB.
13 авг 06, 15:54    [2996994]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Pantalone
Места кушает в несколько раз больше других вариантов, того же FB.

Да что вы говорите... Прям таки в несколько раз... Ну кто бы мог подумать...
А за счет чего FB в несколько раз меньше места занимает, можно полюбопытствовать?
Наверное в FB в одном байте дискового пространства умудряются сохранять десять байт полезной информации?
13 авг 06, 16:08    [2997006]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Pantalone
При больших обхемах он далеко не лучший. Места кушает в несколько раз больше других вариантов, того же FB.

А можно поинтересоваться, когда меряется место - в активном или пассивном состояниях ? Просто как бы памятуя о способе организации хранения цепочек версионности внутри БД, как то слабо в это вериться в это утверждение для активно работающих баз FB, в которых будет необходимо чистить мусор.

Пьяный Лох
Наверное в FB в одном байте дискового пространства умудряются сохранять десять байт полезной информации?

Ну если вспомнить, что FB все строковые типы хранит в сжатом виде, то типа того ;)
13 авг 06, 19:09    [2997181]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32886

Привет, ASCRUS!
Ты пишешь:

ASCRUS
Пьяный Лох
Наверное в FB в одном байте дискового пространства
умудряются сохранять десять байт полезной информации?

A> Ну если вспомнить, что FB все строковые типы хранит в сжатом виде, то типа того ;)

Пакуется запись. Целиком.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

13 авг 06, 19:21    [2997194]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Пьяный Лох
Да что вы говорите... Прям таки в несколько раз... Ну кто бы мог подумать...
А за счет чего FB в несколько раз меньше места занимает, можно полюбопытствовать?
Наверное в FB в одном байте дискового пространства умудряются сохранять десять байт полезной информации?
Бывает и так. Особенно в индексах
13 авг 06, 19:26    [2997200]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
$tanch
Guest
Уважаемые господа!
У меня аналогичная проблема - файловая БД, клиент на c++. И у меня есть конкретные претензии к акцессу - урезанная работа с полями МЕМО. Как я уже читал тут, они транкейтятся до 255 символов при использовании в GROUP BY или DISTINCT... Плюс ещё Jet почему-то не ест поля МЕМО в подзапросах [e.g. SELECT * FROM db.T1 WHERE col1 IN (SELECT column1 FROM db.T2 WHERE colunm2 LIKE '..%') - все поля типа MEMO], хотя это может быть уже кривые руки, а не акцесс %) Энивей, есть ли какой-нибудь файловый вариант, сопоставимый по скорости (ну, в крайнем случае - не намного тормознее) и работающий с длиннотекстовыми полями? =)
P.S. А VFP отказался по МЕМО делать Primary Key...
16 авг 06, 14:49    [3010951]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
автор
А VFP отказался по МЕМО делать Primary Key...


А что за задача такая, что Вам по мемо надо PK делать?! И что подвергло Вас на "все поля типа мемо"? Не буду говорить за все СУБД, но MS SQL "не умеет" делать индексы по полям типа ntext, text, или image.
16 авг 06, 15:56    [3011552]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Stanch
Guest
В акцессе, как я понимаю, два типа текстовых - "МЕМО" и "текст".
У меня БД по данным о mp3-файлах (автор, название и пр.). Ключом в таблице должно быть имя файла - я не уверен, что ограничение в 255 символов, предлагаемое в поле типа "текст", тут уместно. Кроме того, акцесс соглашался индексировать по МЕМО %)
Вообще, хотелось бы все поля в таблице иметь длиннотекстовых типов (по крайней мере, без ощутимых ограничений) - varchar или text SQLевские подошли бы, но Акцесс с ними не владах...
Думаю вот о переходе на FB, но я слышал, что он начинает тормозить при кол-ве записей ~1000, хотя по поддержке SQL он богаче Акцесса, это уж точно.
16 авг 06, 16:05    [3011634]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
zloy den
Member

Откуда:
Сообщений: 2579
Stanch
В акцессе, как я понимаю, два типа текстовых - "МЕМО" и "текст".
У меня БД по данным о mp3-файлах (автор, название и пр.). Ключом в таблице должно быть имя файла - я не уверен, что ограничение в 255 символов, предлагаемое в поле типа "текст", тут уместно. Кроме того, акцесс соглашался индексировать по МЕМО %)
Вообще, хотелось бы все поля в таблице иметь длиннотекстовых типов (по крайней мере, без ощутимых ограничений) - varchar или text SQLевские подошли бы, но Акцесс с ними не владах...
Думаю вот о переходе на FB, но я слышал, что он начинает тормозить при кол-ве записей ~1000, хотя по поддержке SQL он богаче Акцесса, это уж точно.

Плакал.
Где эту глупость сказали?
16 авг 06, 16:21    [3011809]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Stanch
У меня БД по данным о mp3-файлах (автор, название и пр.). Ключом в таблице должно быть имя файла - я не уверен, что ограничение в 255 символов, предлагаемое в поле типа "текст", тут уместно. Кроме того, акцесс соглашался индексировать по МЕМО %)


Эээ... MS SQL имеет тип данных varchar(n), где n от 1 до 8000. И их естественно стоит индексировать. Но вот стрить на нем PK... Я сторонник суррогатных ключей, а на имени файла в таком случаи вешается UNIQUE CONSTRAINT.

Stanch
Вообще, хотелось бы все поля в таблице иметь длиннотекстовых типов (по крайней мере, без ощутимых ограничений) - varchar или text SQLевские подошли бы, но Акцесс с ними не владах...


Если меня не подводит память, то Access вполне успешно работает с полями тип varchar или text.
16 авг 06, 16:26    [3011863]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Stanch
Guest
pkarklin
Эээ... MS SQL имеет тип данных varchar(n), где n от 1 до 8000. И их естественно стоит индексировать. Но вот стрить на нем PK... Я сторонник суррогатных ключей, а на имени файла в таком случаи вешается UNIQUE CONSTRAINT.

Хорошо. Пусть будет UC. Но если бы всё было так хорошо ) Мой VFP и это отказывается делать ) Ну чёрт с ним. Он у меня вообще случайно да и то 6й версии (бугагага), и возможности (и желания) обновлять нет.
pkarklin
Если меня не подводит память, то Access вполне успешно работает с полями тип varchar или text.

Либо Вас подводит память, либо что-то подводит меня %)
Только что пробовал такие запросы:
ALTER TABLE db.Tags ADD TestCol1 varchar (1000) /*(1)*/
ALTER TABLE db.Tags ADD TestCol2 text /*(2)*/
ALTER TABLE db.Tags ADD TestCol3 text (1000) /*(3)*/
Результат:
(1) - ругается на слишком длинное поле
(2) - создаёт колонку типа "Текст" длиной в 255 символов
(3) - ругается на слишком длинное поле
Кроме того, в самом Акцессе (при редактировании таблицы) - ни слова о текстовых типах кроме "Текст" и "Поле МЕМО"
16 авг 06, 16:44    [3012079]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
Stanch
Guest
zloy_den
Плакал.
Где эту глупость сказали?

Допустим глупость) Тогда хотелось бы услышать конструктивное предложение: решит ли FB вышеуказанные проблемы? Если нет, то что решит?
(предложенный вариант, естесственно, должен подходить под описанную ситуацию - бесплатная БД, которую можно без зазрений совести и физическиз трудностей таскать за программой)
16 авг 06, 16:48    [3012134]     Ответить | Цитировать Сообщить модератору
 Re: опять про выбор БД (аналоги аксесса)  [new]
zloy den
Member

Откуда:
Сообщений: 2579
Легко
Embedded версия firebird
16 авг 06, 16:55    [3012227]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить