Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
 Re: Сравнение DBF и SQL-сервер  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
Давайте вспомним про OLAP... К примеру для MSSQL...

Вы все еще считаете что dbf-ки смогут тягаться?


а давайте ещё вспомним про почту. К примеру для Lotus Domino. И выяснится что домино это самый крутой скл-сервер.
26 фев 05, 00:02    [1346661]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
karly™
Guest
andy st
каких-либо действий по оптимизации (создание индексов, оптимизация струкрур таблиц) со стороны сопровождающих систему людей не предвидится в принципе.
Т.е. виноваты разработчики, а не возможности ПО?
Кстати, вы можете добавить нужные индексы самостоятельно. Скорее всего, система этого даже не заметит, и будет автоматически поддерживать их в актуальном состоянии. Если только разработчики не пользуются "собственным патентованным средством доступа к данным"


Александр Гoлдун
Личный пример - падение сервера по причине того, что закончилось место на диске с transaction log. База была повреждена. Скорее всего незначительно, без потерь данных и с возможностью починки штатными средствами, но я не стал с этим заморачиваться. Я просто поднял бэкап, который был сделан примерно за минут до этого по расписанию. Везение? Да. Но вероятность такого везения была высока за счет того, что тогда бэкап делался раз в час. Инкрементальный, естественно. Можно себе такое на VFP позволить?
Вы сами спровоцировали проблему, и сами из нее выпутались. Данный пример ни о чем не говорит.

Александр Гoлдун
Если вы считаете это главным или единственным преимуществом SQL-серверов перед DBF, то смею предположить, что вы очень мало знакомы с клиент-серверверными технологиями доступа к данным, не смотря на упоминаемый опыт работы с Sybase ASA
Я работал - сюрприз! сюрприз! - в самом Sybase. А сейчас я являюсь PM интернет-проекта, в качестве средства разработки использующего MySQL и Perl.

Ну, и напоследок.
Александр Гoлдун
Я ни в коем случае не пророчу смерть dbf. И вообще я ничего не имею против dbf. Я лишь против фанатизма и непрофессионального подхода при решении задач. Мне обычно ставятся задачи в бизнес-терминах, я сам принимаю решения по технологии и несу полную ответственность за результат. Включая как стоимость разработки, так и пресловутое TCO. И если больше подойдет dbf, я возьму dbf.
А если больше подойтет Oracle, возьмете именно его? Мне нечего добавить. Подписываюсь под каждым словом.
26 фев 05, 00:07    [1346662]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Ну сколько можно об одном и том
ASCRUS
кто мешает взять дешевый, а то и вообще бесплатный СУБД, откуда взялось мнение, что КС нужно использовать только там, где большие обьемы данных ? Ничего подобного - КС в отличие от ФС гарантирует большую надежность и скорость, защищенность и согласнованность данных, а так же достаточно широкую функциональность, которую в полном обьеме не сможет предложить ни один ФС и уж тем более FoxPro.
Опять двадцать-пять. Читайте в начале топика. КС не гарантирует большую скорость, даже скорее наоборот, в скорости проиграет.

При определенном и достаточно редком сочетании условий. Как то: 1 пользователь, база на локальном диске, мощность компа сравнима с мощностью сервера или что-то около того.
Ну сколько можно об одном и том

У КС есть функциональность, отличающаяся от ФС, но и обратное утверждение тоже верно. При использовании КС действительно можно получить большую защищенность данных, но это только в случае применения комплекса мер безопасности. А если пароль к БД хранится в ini-файле в открытом виде, или любой пользователь может сформировать отчет по всем клиентам за весь период времени, и отправить на печать - о какой защищенности данных вы говорите? И только не надо рассказывать, что у вас таких дыр в безопасности нет.

У меня таких нет. Если у вас пароль в ini, то я сочувствую во вторую очередь вам, а в первую очередь вашим клиентам или вашему работодателю.
Я могу к своим бд дать SQL-доступ квалифицированному разработчику помимо основного клиентского приложения, добавить к этому структуру БД с комментариями и буду уверен в том, что он
а) не нарушит целостность
б) не испортит имеющиеся данные
в) не увидит лишнего.
Но при этом будет иметь достаточно прав для работы, включающей выборки, добавление, модификацию и удаление данных.

У вас не так? Я бы не взял вас на работу и не купил бы ваш софт.
Вы именно по этой причине пишете сюда анонимно?
Ну сколько можно об одном и том

ASCRUS
берете тот же недорогой Sybase ASA или бесплатный FireBird и лепите себе клиента на Sybase PowerBuilder
...и насладитесь полным набором глюков, которым славится PB...

Это уже мимо темы. Клиентскую часть можно писать на чем угодно. Хоть на FoxPro.
Ну сколько можно об одном и том

ASCRUS
на выходе получаем систему, которая уже на первых пнях будет прекрасно себя чувствовать и по затратам на создание в разы превосходить ФС по той простой причине, что уже все есть
Осталось выяснить, чего по вашему мнению в ФС нет

Ну сколько можно, уважаемый Ну сколько можно об одном и том?
Уже 5 страниц исписали. Идем по кругу?
Ну сколько можно об одном и том

P.S. Не надо думать, что я ярый сторонник ФС. Я - за мирное сосуществование :-) И еще мне не нравится, когда для обоснования своих убеждений, люди начинают придумывать всякие басни.

Особенно про хранение паролей в ini файлах.
26 фев 05, 00:28    [1346682]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
karly™

Александр Гoлдун
Личный пример - падение сервера по причине того, что закончилось место на диске с transaction log. База была повреждена. Скорее всего незначительно, без потерь данных и с возможностью починки штатными средствами, но я не стал с этим заморачиваться. Я просто поднял бэкап, который был сделан примерно за минут до этого по расписанию. Везение? Да. Но вероятность такого везения была высока за счет того, что тогда бэкап делался раз в час. Инкрементальный, естественно. Можно себе такое на VFP позволить?
Вы сами спровоцировали проблему, и сами из нее выпутались. Данный пример ни о чем не говорит.

А КАКОЙ ДОЛЖЕН БЫТЬ ПРИМЕР, ЧТОБЫ ГОВОРИЛ О ПОЛЬЗЕ BACKUP?
Как это я спровоцировал проблему? Ее так же могла спровоцировать элементарная физическая поломка HDD, выход из строя контроллера, взбесившаяся ОС, протекание воды с верхнего этажа. Есть достаточно прочих примеров.
karly™

Александр Гoлдун
Если вы считаете это главным или единственным преимуществом SQL-серверов перед DBF, то смею предположить, что вы очень мало знакомы с клиент-серверверными технологиями доступа к данным, не смотря на упоминаемый опыт работы с Sybase ASA
Я работал - сюрприз! сюрприз! - в самом Sybase. А сейчас я являюсь PM интернет-проекта, в качестве средства разработки использующего MySQL и Perl.

И вы по прежнему считаете главным преимуществом SQL перед DBF возможность шифрования и отсутствие ограничения объема? А горячие бэкапы и разграничение доступа считаете нужным только для интернет-магазинов и учетных систем с кол-вом пользователей >50?
Кстати, а кто кроме ASA еще поддерживает шифрование на уровне БД? Что-то не припомню.

karly™

Ну, и напоследок.
Александр Гoлдун
Я ни в коем случае не пророчу смерть dbf. И вообще я ничего не имею против dbf. Я лишь против фанатизма и непрофессионального подхода при решении задач. Мне обычно ставятся задачи в бизнес-терминах, я сам принимаю решения по технологии и несу полную ответственность за результат. Включая как стоимость разработки, так и пресловутое TCO. И если больше подойдет dbf, я возьму dbf.
А если больше подойтет Oracle, возьмете именно его? Мне нечего добавить. Подписываюсь под каждым словом.

Возьму, но пока не сталкивался с такими условиями, при которых Oracle подойдет больше ASA. Такие есть, но их тоже не так много.
26 фев 05, 00:53    [1346689]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
karly™
Guest
Александр Гoлдун
некто
КС не гарантирует большую скорость, даже скорее наоборот, в скорости проиграет.

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

- оптимизированные запросы будут выполняться либо так же, как на КС, либо быстрее
- добавление данных выполняется намного быстрее, чем у КС. Особенно это заметно при массовых операциях
- запросы, требующие группировки, на ФС очевидно медленнее, но не настолько, насколько можно было бы ожидать
- ФС полнотью пролетает в случае полнотекстового поиска
- если требуемые данные - не простой запрос, а результат выполнения (хранимой) процедуры, то все зависит от реализации. Одна и та же задача в ФС и КС может решаться совершенно по разному, и с разным быстродействием. Именно тут проявляется "различие идеологий ФС и КС"

Александр Гoлдун
И вы по прежнему считаете главным преимуществом SQL перед DBF возможность шифрования и отсутствие ограничения объема? А горячие бэкапы и разграничение доступа считаете нужным только для интернет-магазинов и учетных систем с кол-вом пользователей >50?
Чуть-чуть не так. Я считаю однозначным преимуществом КС перед ФС разграничение доступа, и отсутствие ограничений по объему. В ФС есть возможность шифровать данные, например в Paradox и Access. А вот dbf зашифровать вряд ли получится.

Горячие бэкапы для систем с небольшим числом пользователей (<50), и не работающих в условиях 7*24, вполне успешно заменяются различными суррогатами. Например, в VFP очень даже несложно писать одни и те же данные на два разных сервера, либо вести лог. Наворачивать в таких условиях комплексную систему резервного копирования - заменять простые проблемы на сложнозамороченные. Как, например, в вашем примере - вы организовали лог на другом сервере, и получили необходимость следить за свободным местом.

Можно упомянуть еще репликацию. В ФС хорошо работает репликация по методу brute force - когда передаются не обновления, а вся база целиком. Например, из центра в филиал - утвержденный прайслист, по которому нужно торговать, из филиала в центр - данные о продажах и остатки на складе. Такой метод часто используют в 1С для обмена с внешними программами.
Если взаимосвязи более сложные (например, общий склад), то однозначно начинают рулить механизмы репликации КС.

Основная идея всего вышесказанного - не стоит разрабатывать распределенную систему вычислений там, где можно обойтись макросом в Excel-е (у меня, к сожалению, такие эксцессы встречались :-(

Александр Гoлдун
пока не сталкивался с такими условиями, при которых Oracle подойдет больше ASA. Такие есть, но их тоже не так много.
Александр, никогда не говорите ничего подобного! А то налетят ораклисты, и такое начнется ;-)
26 фев 05, 02:01    [1346719]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
karly™
Александр Гoлдун
некто
КС не гарантирует большую скорость, даже скорее наоборот, в скорости проиграет.

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

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

Все верно, но ключевое слово - оптимизированные. В моих системах очень многие запросы строятся динамически и предугадать их тяжело. Тут КС вне конкуренции. Я понимаю, что аппетит приходит во время еды и можно было бы отказаться от 80% возможностей как от излишеств, сделанных только потому, что их можно было сделать с минимальными затратами. Но! Но дело в том, что не только поэтому они сделаны. Они приносят в разных направлениях реальный эффект, который можно заметить и иногда даже посчтать. Проще всего это заметить на экономии рабочего времени исполниелей. Чуть сложнее посчитать эффект от больших возможностей анализа (те самые группировки и т.п.), но этот эффект может оказаться значительно больше, чем банальная экономия времени, так как больше возможностей делать выводы для принятия решений, особенно в условиях жесткой конкуренции и дефицита оборотных средств. OLAP - это не только рекламный слоган.

И еще момент, когда даже оптимизированные запросы на ФС не будут работать быстрее - это когда проявляется эффект от использования общего кэша на КС.
karly™

- добавление данных выполняется намного быстрее, чем у КС. Особенно это заметно при массовых операциях

Бесспорно. Для снятия данных с датчиков в реальном режиме времени я не буду ставить КС. Здесь будет либо чистый dbf или что-то подобное, либо буферизация на ФС перед КС. Либо поищу RT SQL-сервер. Но такие вещи в учетных системах встречаются редко. А вот для операторского ввода данных это замедление в общем случае несущественно.
karly™

- запросы, требующие группировки, на ФС очевидно медленнее, но не настолько, насколько можно было бы ожидать

Не знаю, сколько можно было бы ожидать. Надо смотреть на реальных вещах.
karly™

- ФС полнотью пролетает в случае полнотекстового поиска

Не только такой, но и любой не по индексам
karly™

- если требуемые данные - не простой запрос, а результат выполнения (хранимой) процедуры, то все зависит от реализации. Одна и та же задача в ФС и КС может решаться совершенно по разному, и с разным быстродействием. Именно тут проявляется "различие идеологий ФС и КС"

И это различие может существенно увеличить стройность и стабильность системы, уменьшить стоимость сопровождения.
karly™

Горячие бэкапы для систем с небольшим числом пользователей (<50), и не работающих в условиях 7*24, вполне успешно заменяются различными суррогатами. Например, в VFP очень даже несложно писать одни и те же данные на два разных сервера, либо вести лог. Наворачивать в таких условиях комплексную систему резервного копирования - заменять простые проблемы на сложнозамороченные. Как, например, в вашем примере - вы организовали лог на другом сервере, и получили необходимость следить за свободным местом.

Вы меня недопоняли. Лог был на том же сервере. Просто кончилось место на диске. Как я уже говорил, бывают и другие ситуации. Эпизодически (примерно раз в 1-2 месяца, точную статистику не снимал) вылетает HDD. Почему при очередном таком вылете не может оказаться серверный диск?
karly™

Можно упомянуть еще репликацию.

Лучше даже не упоминать. У меня она очень активно используется в разных проявлениях. Тут я с ASA не только dbf, но и большинство SQL-серверов заткну с их репликаторами ;) По крайней мере в рамках некоторых (или многих) постановок условий.
karly™

Основная идея всего вышесказанного - не стоит разрабатывать распределенную систему вычислений там, где можно обойтись макросом в Excel-е (у меня, к сожалению, такие эксцессы встречались :-(

Соглашусь. Мне вот еще не нравится, когда для архивирования бэкапов используется rar + самописная программа, добавляющая к имени архива дату. А можно было просто набрать rar /? и прочитать про ключ -ag. Но этот же принцип может действовать и против ФС в пользу КС.

На текущий момент даже для систем с одним пользователем я скорее предпочту десктопный вариант какого-нибудь сервера. Хотя бы из-за преемственности кода, идеологии, технологий. Но даже без учета этой преемственности не исключено, что КС в такой задаче окажется дешевле в реализации и эксплуатации.
karly™

Александр Гoлдун
пока не сталкивался с такими условиями, при которых Oracle подойдет больше ASA. Такие есть, но их тоже не так много.
Александр, никогда не говорите ничего подобного! А то налетят ораклисты, и такое начнется ;-)

С ними спорить абстрактно ломает. Вот сойдемся в тендере - тогда посмотрим. Заочно без боя сдаю позиции крутых систем с тысячами юзеров и распределенными кластерами. А еще оптимизатор Oracle в отличие от ASA умеет на условиях OR подхватывать по два индекса на таблицу.
26 фев 05, 04:18    [1346743]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
Александр Гoлдун
А еще оптимизатор Oracle в отличие от ASA умеет на условиях OR подхватывать по два индекса на таблицу.
Вы никогда не задумывались, что если бы это было главным в оптимизации, то таковая возможность была включена во все, уважающие себя, СУБД. Прочитать 2 индекса, слить их, а затем по RID-ам найти эти записи в самой таблице... Есть сильное сомнение, что сей процесс выгоден безусловно, разве при сильно специфических условиях. Это как возможность создать в БД десятки тысяч таблиц, а если вернутся к реальности ?
26 фев 05, 12:23    [1346916]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Александр Гoлдун
А еще оптимизатор Oracle в отличие от ASA умеет на условиях OR подхватывать по два индекса на таблицу.

В FoxPro это реализовано десяток лет назад И работает прекрасно...
26 фев 05, 13:35    [1346967]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Почему я ушел от DBF и DB.
Малейший сбой сети или клиентского компа могло привести и часто приводило к падению индексов и/или зависанию блокировок. А такого кошмара, как сбой счетчика записей в заголовке DBF-файла я не пожелаю никому. Или вспомнилось наличие посредине DBF-файла куска с текстом прайс-листа. Ну подумаешь, общие кластеры при выключении зависшего компа образовались.
Причем эти милые мелочи сразу не проявлялись.

Все-таки вероятность проблем на N рабочих станциях, как минимум N раз больше, чем на одном сервере.
26 фев 05, 17:32    [1347173]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Cat2

Почему я ушел от DBF и DB.

Так DBF и DB для того и есть еще в наше время, чтобы с них нужно было уходить не объясняя причин. С другой стороны, отдавая дань уважения к их вкладу в развитие инфо технологий на своем историческом отрезке, многие, и я в том числе, даем расширение DBF файлам данных и в Оракловых базах.
26 фев 05, 18:10    [1347205]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
Cat2
Почему я ушел от DBF и DB.
В том же плане- с грустью смотрю на свое творение, некую сложную справку 4-х годичной (или более?) давности. Delphi+BDE+Paradox. Поля для хранения временных значений, выборка, заполнение полей, другая выборка, заполнение других полей, и т.д- 4-5 раз. Возможности LocalSQL не позволяли большее. С сегодняшней точки зрения, на КС технологии, можно сделать через одну ХП в которой несколько запросов с подзапросами. Первый вариант сегодня практически невозможно как-то редактировать- легче снова написать.
26 фев 05, 18:58    [1347228]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Александр Гoлдун

Кстати, а кто кроме ASA еще поддерживает шифрование на уровне БД? Что-то не припомню.


Versant.
26 фев 05, 20:57    [1347298]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Alexey Rovdo
Александр Гoлдун

Кстати, а кто кроме ASA еще поддерживает шифрование на уровне БД? Что-то не припомню.

Versant.

Это что за чудо? Не припомню такого SQL-сервера. Oracle помню. MSSQL, Informix, DB2, Sybase ASE, PostgreSQL, FB, MySQL помню. Даже про Linter слышал.

Это что-то из соседних многостраничных флеймов?
26 фев 05, 23:02    [1347361]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Гoлдун

Это что за чудо? Не припомню такого SQL-сервера.

А это не и SQL-сервер, и даже вообще не РСУБД. Это ООСУБД. Причем она там у них похоже, занимает такое же место, как Sybase среди SQL-серверов. Т.е. вполне уважаемый представитель от их клана. Не какой-нибудь там не понятно кто, ни где в серьезной литературе по БД толком не упоминаемый.
27 фев 05, 00:23    [1347403]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
vadiminfo
Александр Гoлдун

Это что за чудо? Не припомню такого SQL-сервера.

А это не и SQL-сервер, и даже вообще не РСУБД. Это ООСУБД.

Я понял намек. Мы тут, убогие, спорим про крутость DBF или SQL, а это оказывается все уже каменный век. Пришло время объектного ориентирования!
27 фев 05, 01:21    [1347424]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Александр Гoлдун
vadiminfo
Александр Гoлдун

Это что за чудо? Не припомню такого SQL-сервера.

А это не и SQL-сервер, и даже вообще не РСУБД. Это ООСУБД.

Я понял намек. Мы тут, убогие, спорим про крутость DBF или SQL, а это оказывается все уже каменный век. Пришло время объектного ориентирования!


Вспомнилось, кстати. В Sybase ASA еще в 6-й версии включили поддержку Java. Можно было использовать методы Java-классов как хранимые процедуры и хранить в полях Java-объекты. А в 9-й версии почему-то убрали возможность хранения java-данных, оставили только возможность использования хранимых процедур на java. К чему бы этот "демарш"?

Впрочем, это тема другого флейма.
27 фев 05, 01:33    [1347426]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Александр Гoлдун
vadiminfo
Александр Гoлдун

Это что за чудо? Не припомню такого SQL-сервера.

А это не и SQL-сервер, и даже вообще не РСУБД. Это ООСУБД.

Я понял намек. Мы тут, убогие, спорим про крутость DBF или SQL, а это оказывается все уже каменный век. Пришло время объектного ориентирования!

Интересно, а к чему этот ваш сарказм?
Вы спросили "кто кроме ASA поддерживает шифрование на уровне БД" - вам ответили.
27 фев 05, 02:19    [1347433]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
А, я понял...
Если мы тут "спорим про крутость DBF или SQL", то не пришей к п**де рукав под названием ASA - упоминать можно, а что-то другое низзя.
27 фев 05, 02:28    [1347438]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Лох Позорный пишет:
> А, я понял...
> Если мы тут "спорим про крутость DBF или SQL", то не пришей к п**де
> рукав под названием ASA - упоминать можно, а что-то другое низзя.

А что вы так нервничаете, Лох Позорный? Я какими-то своими
высказываниями задел вас или запретил что-то упоминать? Просмотрел свои
постинги - ничего подобного не нашел. Померещилось, наверное, от
мнительности.

А что касается ASA, я упомянул тут его в основном по той причине, что
здесь приводилось шифрование данных, как преимущество SQL-серверов перед
файл-серверными СУБД. А мне неизвестны кроме ASA другие SQL-сервера,
которые шифруют на уровне БД. По крайней мере этого не делают MSSQL,
ASE, Линтер, Oracle. В FB возможно в будущем появится подобная
возможность. Про прочие не знаю, но похоже тоже не шифруют. Но я могу и
ошибаться. Вот в этом контексте я и поинтересовался, кто еще из
SQL-серверов имеет такую возможность.

Posted via ActualForum NNTP Server 1.1

27 фев 05, 04:26    [1347460]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
mod
Member

Откуда:
Сообщений: 2318
Ладно, понял... всех понесло.... Сам виноват...
Всё о чём дискутировалось выше во-первых итак понятно, а во-вторых неоднозначно...
1. Забегая вперёд, я уже как-то конвертил dbf-файлы в MySQL (есть такая утиля dbf2mysql).
По средсвам это ничего не стоило. Ибо и утиля бесплатна и MySQL даже при коммерческом ипользовании чисто символически стоит
(и докажи ещё что я коммерчески использую, то есть с целью извлечения прибыли получаю, а не для поокрытия расходов за работу).. Из Access в MsSQL Server 2000 тоже помнится при помощи Import and Export Data не велика проблема...
На самом деле я тогда в MySQL конвертил тока потому что удобнее на Perl(DBI.pm, DBD-MySQL.pm) было скрипты с запросами и генерацией HTML(CGi.pm, DataTable.pm) к нему писать...
Это да, переход от ФС на КС, но суть разница в MySQL также таблицы на диске хранятся в обычном каталоге, в обычных файлах. Имена файлов соответсвуют имени таблицы, Имя каталога-имени базы. Всё как с dbf. Однако, использвание MySQL как надстройки для обработки тех же SQL-запросов весьма удобно...
(Благо запросы были тупыми: select * from ...). На самом деле и юзеров можно в dbf хранить(это про критику ini), а шифровать вам кто мешает (да нужно ли?). Много вы шифруете?
Не будем 1С обсуждать, там без матюгов никак, да и не к чему...
Недостатки из-за "кривизны" системы тоже не довод. Где вы видели "не кривую"?
Под переводом из dbf в SQL я подразумеваю именно смену идеологии, а как следствие придётся менять и структуру базы(кстати уже изменил).
Фокспрошникам не надо сечас гворить что в Фоксе мол тоже единые базы из нескольких таблиц появились благодаря контейнерам, они и в Access давно есть, как кстати и ключи...
Против Access вообще ничего плохого сказать нельзя: ВЕЩЬ! Во многих случаях разумно использовать именно её, а то некоторые на Oracle сразу начинают мелкие базы наворачивать(хорошо если ещё Oracle 7, а то и 9 берут)... Энто уже маразм. Фокс тоже изумителен если надо быстро сделать базу с пользовательским интерфейсом (и повторюсь это всё таки язык программирования баз данных, как и Clipper, а не SQL! SQL-запросы там вообще чужеродны и только для совместимости)...
2. Суть в том что начальство, которому сдаются результаты изначально поставило задачу сделать клиент-сервер, при это начальство заядлые фокспрошники и под сервером подразумевают именно просто сервер(файл-сервер).
А клиента по их мысли можна и на Фоксе генерить с COM-объектами (и кстати весьма просто, не сложнее чем на тех же Дельфях клиента писать) и HTML/XML-формы и таблицы он генерит. Всё работает.
Доводы типа Фокс устарел не катят - мол эту технологию сами Микромягкие продвигают и выпускают всё новые версии с новыми возможностями! И как сервер Фокс прижелании можно юзать... И вообще, это единственный язык программирования баз данных! значит не устарело! Попробуйте убедительно опровергнуть.
Сам на Фоксе писал ещё на 2.6 и с VFP8 сталкивался.... Весте с тем начальство требует обоснования отказа от FoxPro(например чтобы в итоге его не получить и спать спокойно ещё десяток лет)...
3. У начальства появилась новая идея: а давайте вообще конвертнём всё в XML и сделаем XML хранилища.Тем паче и структуру менять не придётся И в духе со временем: типа XML и у Микромягких рулит...И не надо никаких SQL. Кстати уже конвертнули и уже работает...
Я сказал что это без меня: Мол не спорю что XML это канечно круто, но...
4. Барьер dbf в 2 GB тоже не катит ибо база была реализована вввиде сотен каталогов в которых хранятся сотни dbf-файлов максимум до 1000 записей. Там и до 1 Мб файлы не доходят. Мало того - эти dbf имеют разную структуру. Связаны они через файлы-каталоги: те же таблицы, в которых хранятся ссылки на другие таблицы.(Понятно что неактуальных ссылок до фига)
Я критиковал такой подход тем, что для создания нового набора данных необходимо создавать новую таблицу(файл), а то и целый каталог - что есть доступ к дискам. И вообще, мол, хрен вы просто получите выборку из всех таблиц даже с несильно отличающимися структурами наборов (отличия бывают в одно-два поля). Короче мол для технологии клиент-сервер не катит не совсем...
5. На самом деле я уже создал структура базы в которой нет такого числа таблиц с разными наборами, а получил несколько но довольно, по мнению начальства, больших таблиц (аж по миллиону записей. смех!) на MsSQl Server. Получилась по ркайней мере единая база, а не набор условно связанных таблиц.... Пришлось, увы использовать тип sql_variant... Зато благодаря PK-FK каскадное удаление и фиг неактуально....
И есле раньше любую таблицу можно было просто выводить(это не интересно, так и в Excel мона навоять), то у меня без JOIN одним запросом и не выведишь(мелочь, а палцы уже пошвырять можно.
6. Задача впарить эту структуру начальству, а их проекты "опустить". Но надо это делать с обоснванием, а не распальцовкой...
Если впарю,то моя структура станет основной, и как следствие, я возглавлю данный проект...
Вот поэтому надо обосновать...
Увы... Впрочем это моя вина: слишком абстактно задачу поставил. В итоге и не получил ответа... Но может после пояснения чего умног посветуете?
Напрямую сравнивать разрозненые dbf-таблицы с моей базой различными тестами, как предложило начальство не катит. Даже если dbf-конвертнуть в Ms SQL Server 2000... Суть в том, что слона с комаром на основании того что у обоих есть хобот сравнивать на то кто из них лучше по численным параметрам (рост, вес, длина хобота) бессмыслено... Тут, на мой взгляд, надо анализ типа слон в отличии от комара хрен взлетит, зато фиг его пальцем раздавишь...
Но я слишком предвзят. Нужны сторнние, обоснованные, глубокие и объективные оценки чтобы не стыдно включить в аналитическую записку...
27 фев 05, 06:20    [1347480]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
FishingIsGood
Member

Откуда:
Сообщений: 133
mod
Ибо и утиля бесплатна и MySQL даже при коммерческом ипользовании чисто символически стоит
(и докажи ещё что я коммерчески использую, то есть с целью извлечения прибыли получаю, а не для поокрытия расходов за работу).


Ничего и доказывать не надо - MySQL респростроняется под GPL (в том числе) и вы имеете полное право использывать его в коммерческих целях не платя ни копейки.
27 фев 05, 09:21    [1347510]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
mod
Member

Откуда:
Сообщений: 2318
Да я про MySQL, так, к слову... Конечно никто не придерётся... Однако я её уже не использую(а жаль)...
28 фев 05, 08:23    [1348200]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Jimmy
Member

Откуда: г.Москва
Сообщений: 3136
SanyL
Jimmy
andy st
karly™
Если есть реальная проблема, постараемся разобраться :)

БОЛЬШОЕ спасибо за желание помочь, но я не уверен, что индексы в принципе смогут помочь на условиях типа
like '65____'
при любом из существующих драйверов. Такое было сделано когда-то и ничего с этим не поделать-приходится ждать. Единственное, что радует - к лету эту систему должны перевести на клиент-серверные рельсы.


Именно для такого случая индексы помочь могут, т.к. поисковое выражение начинается со значимых символов, т.е. можно использовать префиксный поиск по индексу (работает в MS SQL, Sybase ASE, FoxPro).

Кроме того, в Фоксе префиксный поиск можно организовать посредством функции SEEK при соответствующих установках SET EXACT|SET NEAR, допускающих поиск первого похожего значения.


На счет MSSQL я с Вами не соглашусь... Опратор Like не использует индексы, возможно к сожалению


См. план запроса для префиксного выражения (INDEX SEEK) и для более свободного условия (INDEX SCAN). В обеих случаях используется индекс, но более продуктивно - для префиксного поиска:
--------------------------------------------------------------------------------
Microsoft SQL Server  2000 - 8.00.818 (Intel X86) 
	May 31 2003 16:08:15 
	Copyright (c) 1988-2003 Microsoft Corporation
	Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 3)

(1 row(s) affected)

[b]Use Northwind[/b]
go

[b]:::[/b]
StmtText
---------------------------------------------------------------------- 
select ShipPostalCode 
from dbo.Orders 
where ShipPostalCode like('31%')

(1 row(s) affected)

StmtText                                                                                                   ----------------------------------------------------------------------
  |--Index Seek(OBJECT:([Northwind].[dbo].[Orders].[ShipPostalCode]), 		SEEK:([Orders].[ShipPostalCode] >= '31' AND [Orders].[ShipPostalCode] < '32'),  
			WHERE:(like([Orders].[ShipPostalCode], '31%', NULL)) ORDERED FORWARD)

(1 row(s) affected)

StmtText                                                                      
---------------------------------------------------------------------- 
select ShipPostalCode 
from dbo.Orders 
where ShipPostalCode like('_3%')

(1 row(s) affected)

StmtText                   
----------------------------------------------------------------------
  |--Index Scan(OBJECT:([Northwind].[dbo].[Orders].[ShipPostalCode]),  
	WHERE:(like([Orders].[ShipPostalCode], '_3%', NULL)))

(1 row(s) affected)

28 фев 05, 10:29    [1348474]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
Crip
Member

Откуда:
Сообщений: 2490
2mod
Попробуйте подойти к вопросу системно.
Распишите детально все приемущества и недостатки обоих подходов (основным приемуществом ФС скорее всего будет выступать наличие уже функционирующей системы)
Присвойте весовые коэффициенты каждому из пунктов. Получите некий интегральный показатель.
Очень хорошо на начальство действует стоимостной анализ, причем в перспективе лет на 10.
В конце концов попробуйте заинтересовать начальство лично. Начальство всегда держится за свое место, причем во многом благодаря знаниям неких устаревших систем и технологий. Попробуйте объяснить, что знания новых технологий пойдет им на пользу и увеличит их ликвидность на рынке труда.
28 фев 05, 11:20    [1348662]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение DBF и SQL-сервер  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mod

Против Access вообще ничего плохого сказать нельзя: ВЕЩЬ! Во многих случаях разумно использовать именно её, а то некоторые на Oracle сразу начинают мелкие базы наворачивать(хорошо если ещё Oracle 7, а то и 9 берут)...

Между прочим - умно поступают. Я вот навоял в Аксцессе. А теперь мучаюсь. Для одних задач в Оракле все есь чего они хотят, а переводить уже не могу по времени. В другом случае из Оракла к Аксцессу подцепился, чтобы отчет тяжелый в ПФ готовить. Причина - Диалект SQL у Оракла выразительней (мощней). То что там писал, еще и сохранял в пром таблах и еще к этому код на Бэйсике писал - здесь одним запросом прокатывает. Это и тестировать легче и проверки данных всякие проще (данные на основе которых отчет с разных БД далеких от идела в том числе и на dbf). Так что если есть возможность то лучше сразу на Оракл. Другое дело всю систему с пользовательским интерфейсом проще в Аксцессе надолбить. А там поковыряиться побольше придется.
28 фев 05, 15:23    [1349804]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить