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

Откуда: Тюмень
Сообщений: 2559
Anasta
MS SQL Server vs MS Access vs Visual Fox Pro

1. Скорость в многопользовательском окружении: 5:0:2
2. Надежность: 5:3:?
3. Простота построения таблиц: 4:5:?
4. Простота построения хранимых процедур: 4:0:?
5. Удобство в работе: 5:5:?
6. Обеспечение достоверности БД: 5:3:?
7. Вопросы безопасности: 5:4:?

Как вы считаете близки ли проставленные мной значения к реальным?
Проставьте, пожалуста, значения вместо "?" для Visual Fox Pro.


Пункт 2: а, скажем, онлайновый бекап базы MS Access вы сделаете? Я поставил бы 0.
Пункты 3,4,5 я просто не понимаю.
По пункту 7 я MS Access'у тоже поставил бы 0. Файл в общем доступе - это большая дыра.
21 июн 06, 23:52    [2799836]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
ы
Victor Metelitsa
Хранимые процедуры хранятся на сервере. Это по самому определению хранимых процедур.

Оригинальное определение.

Вот что нам по этому поводу говорит BOL:
stored procedure
A precompiled collection of Transact-SQL statements stored under a name and processed as a unit. SQL Server supplies stored procedures for managing SQL Server and displaying information about databases and users.

Собственно под это определение подпадают акцессовские запросы update, insert into, delete, alter и др. Которые никто, кстати, не запрещает хранить на сервере. :))


И где, по-вашему, может быть stored и processed "A precompiled collection of Transact-SQL statements stored under a name and processed as a unit", если не только на сервере? По-моему, если тут слово server и не стоит, то только в виду самоочевидности. Вообще, вырывая слова из контекста, можно многого "достичь" ("Было бы величайшей ошибкой думать". В.И.Ленин, ПСС, т.41, с.55. - цитата с lib.ru), но таким приёмам грош цена.


Какое к этому имеют отношение "акцессовские запросы update, insert into, delete, alter и др", бог вас знает.
22 июн 06, 00:00    [2799847]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
2 Victor Metelitsa :

п 5 - видимо имеется ввиду обеспечение целостности
к STORED PROCEDURE в аксессе имеют некоторое отношение параметризованные запросы
22 июн 06, 00:14    [2799861]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ы
Guest
Victor Metelitsa
...
Но это совсем не то, что предлагают нормальные SQL-сервера, даже если выглядит похоже и называется также.
...

Мне кажется, в постановке вопроса Вы нашли себе другой вопрос: отличия файл-серверных систем от клиент-серверных. И доказываете внимательным читателям, что они таки есть! :)
Поверьте, товарищ ЛП знает это не хуже Вас, пусть и в несколько развязной форме об этом сообщает :)
Вам можно почитать это.

Да, и (не говорю про FoxPro, хотя не удивлюсь, если в нем есть аналоги) Access
автор
Про систему GRANT'ов (на TABLE, VIEW, PROCEDURE и т.д.) даже не спрашиваю.

- умеет давать и использовать разрешения на различные действия с таблицами/запросами и другими своими объектами.
автор
А кто вас пустит к файлам, чтобы проделать такой фокус с MS SQL (предполагая, что вы не админ с суицидными наклонностями)?

- это, и многое из сказанного рядом, решает упомянутый терминал-сервер.
автор
Пункт 2: а, скажем, онлайновый бекап базы MS Access вы сделаете? Я поставил бы 0.

- сделаете. Простым копированием файла БД. Мало того, вероятно, и пользователи после этого остануться работать, и файл у вас получиться рабочий. Хотя конечно, лучше его делать с помощью Access'a из одной из сессий. И не будет никаких проблем. Вопрос вполне решаемый.
автор
По-моему, если тут слово server и не стоит, то только в виду самоочевидности.

Цитата не вырвана из контекста. Вы можете ее получить, открыв БОЛ и ткнув в подсвеченное словосочетание stored procedure в любой статье, где его встретите. Каюсь, отрезано последнее предложение, вот оно: "SQL Server-supplied stored procedures are called system stored procedures."
"В виду самоочевидности" на чертежах на болтах резьбу не пропускают, к слову.
И все-таки, покажете ли вы, почему под это определение нельзя подвести запросы акцесса? Которые пусть даже будут храниться на сервере, о чем в условиях не сказано.
22 июн 06, 00:16    [2799864]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ы
Guest
2 Victor Metelitsa
Я тут в соседнем топике встретил упоминания о том, с чем вы работаете. Признайтесь честно, а вы с файл сервером каким-нибудь более-менее "плотно" работали? Не с самописными курсовыми, и не с 1С-овскими монстрами, работающими на .dbf?
22 июн 06, 00:33    [2799877]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
vadiminfo
Member

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

Итак, начнём с хранимых процедур и триггеров. IBM определяет stored procedure как An application program, possibly containing SQL statements, that is stored on the database server and can be invoked with the SQL CALL statement.

Но, возможно, IBM дает определение под свои системы, которые клинт-серверные, чтобы не обременять себя чем-то лишним. Возможно, имеет значение только то, что они хранятся в БД.
И детали реализации сетевых архитектур (файл серверные, клиент серверные, либо еще какие-то, если появятся), не должны влиять на это понятие, так как оно логическое, а те физические. Если процедура хранится в БД и вызывается на события в БД, то функционал понятия триггер выполнен. Это логика работы - при изменени таблы, кто бы, с какого компа это не делал вызовется процедура. Вроде больше ничего не надо, чтобы быть триггером.
По крайней мере, читал где-то, что в Фоксе есть триггера. Уже по этому на дипломе сказать что их там нет, скорее всего, лишний риск.
22 июн 06, 00:33    [2799878]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
прикольный топег...

Почитаешь ЛП, и думаешь, блин, ах фокспро, ах сукин сын. И транзакции у него и хранимые процедуры. И щож мы тут все тупые SQL сервера юзаем.

ЛП
Сначала ответьте на вопрос - кто в файл-серверной архитектуре занимается выполнением например SQL-запросов по отношению к данным, хранящимся на сервере.
Потом ответьте на вопрос - кто в файл-серверной архитектуре занимается например контролем DRI, типа каскадного обновления/удаления записей связанных таблиц.
Ну а потом попробуйте ответить на вопрос - кто мешает этому "кому-то" исполнять не только "элементарные" sql-запросы, но и "неэлементарные" хранимые процедуры (где бы они ни хранились и что бы они из себя не представляли).
Если не сумеете ответить - это будет Вашим домашним заданием.


Вот тут Вы в самую точку попали, а действительно, КТО?! В К\С СУБД этим занимается ЕДИНСТВЕННЫЙ реляционный движок и именно через этот единственный движек ходят все к данным. А что с фокспро (да и с любой другой Ф\С СУБД) - сколько клиентов, столько и движков. Надеюсь, что дальше не надо объяснять про контроль DRI, транзакции и т.п?!

Достаточно взять букварь по архитектуре какого-нибудь сервера СУБД и посмотреть, как там все это реализовано. Особенно в плане транзакций. Была уже тут перепалка по этому поводу. Честная поддержка транзакций невозможна без централизованного движка и ведения write-ahead лога. Все остальное - от лукавого, хоть 100 раз скажите, что фокс (аксес) поддерживает транзакции, транзакциями в истинном их смысле они никогда не станут.

То же самое и с надежностью - наличие Nого кол-ва движков, работающих практически независимо друг от друга - вот основная причина ненадежности.


PL99
Более того, как только Ваше приложение завершит работу, от ссылочной целостности и каскадных обновлений не останется и следа.


ЛП
Абассаца.
В сад.
Читать буквари.


Нука-нука???!!! И кто будет ее поддерживать, если не одно клиентское приложение (ни один движк) не работает??? Буквари читать надо кому-то другому!!!

ЛП
Гыыы... Таки думаете, что если написать программу, пишущую в обход всего напрямую в файл данных, то MS SQL нельзя порушить (какую-нибудь ссылочную целостность, например)?
Абассаца.
В сад.
Читать буквари.


Ну а это высказывание уже перекрывает все допустимые рамки дебилизма. Флаг Вам в руки!!! Как напишите такую программу, так пришлете мне ее, и я попробую "порушить" свой MS SQL. Готов это сделать на продакшен сервере! Все необходимые права есть!

ЛП
Стоп. А откуда это взялось - "по сетке тягать"? Только что ж было "многопользовательская работа", безо всякого упоминания сетки? Не приходит в голову, что можно, например, через терминальный сервер всех запустить? И пусть себе локально гоняют одно большое файло. Это раз.


Ааа... Уссаться... Боремся не с причиной, а со следствием!

ЛП
Далее. Файлы по сетке гонять - типа западло, а стописят юзеров своими тупыми запросами будут один сервак убивать - не западло? В ФС сетка узкое место, в КС - сервак. Что окажется уже в каждом конкретном случае - бабка надвое сказала.


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

Итого... Скоко бы здесь уважаемые аппологеты Ф\С СУБД не сотрясали воздух - их место (Ф\С СУБД) на свалке истории.

Ну, понеслось... ;)
22 июн 06, 09:44    [2800376]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
К\С СУБД этим занимается ЕДИНСТВЕННЫЙ реляционный движок и именно через этот единственный движек ходят все к данным. А что с фокспро (да и с любой другой Ф\С СУБД) - сколько клиентов, столько и движков


в случае одного движка и одного хранилища "контроль DRI, транзакции и т.п" обеспечивает один движок, в случае движка на каждом клиенте и одного хранилища данных "контроль DRI, транзакции и т.п" обеспечивают все движки.

Второй вариант сложнее и менее надёжен первый вариант проще а значит более надёжен.

Ничего сверхестественного
22 июн 06, 10:03    [2800460]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
1024
в случае одного движка и одного хранилища "контроль DRI, транзакции и т.п" обеспечивает один движок, в случае движка на каждом клиенте и одного хранилища данных "контроль DRI, транзакции и т.п" обеспечивают все движки.

Второй вариант сложнее и менее надёжен первый вариант проще а значит более надёжен.

Ничего сверхестественного


Понятие менее\более не применимо ни к DRI, ни к транзакциям. Они или есть, или их нет. А ненадежная поддерка DRI и транзакций, это все равно что "чуть-чуть беременна".
22 июн 06, 10:11    [2800498]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
жизнь слишком сложная штука чтоб так однозначно делить. Советую более реалистично смотреть на мир.

Посыпался винт. Данные читаются но какая-то их часть, скажем десяток таблиц, невалидна. Встречается достаточно часто, можно посмотреть поиском по любому из разделов скл.ру, попадается и у мсскл и у оракла. Т.е. транзакции и дри имеет степень надёжности ВСЕГДА. Вопрос в количестве, что-то более надёжно, что-то менее.
22 июн 06, 10:21    [2800556]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
1024
Посыпался винт. Данные читаются но какая-то их часть, скажем десяток таблиц, невалидна.


Мне не совсем понятно, зачем Вы приплетаете аппаратные проблемы (которые решаются совсе другими методами) к обсуждения програмной реализации той или иной фичи в Ф\С и К\С СУБД?! Получается как в том вопросе армянского радио: "Сколько нужно программистов, чтоб заменить перегоревшую лампочку? Ответ: нисколько. Проблемма аппаратная, программными способами не решается."

1024
Т.е. транзакции и дри имеет степень надёжности ВСЕГДА. Вопрос в количестве, что-то более надёжно, что-то менее.


А я и не говорил об АБСОЛЮТНОЙ надежности К\С СУБД! Я говорил о том, что то, что называют поддержкой DRI и транзакционной целостности в Ф\С и К\С СУБД суть две большие разницы.
22 июн 06, 10:31    [2800602]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
H5N1
Guest
неа, это встречаются необразованые люди которые не понимают элементарных вещей хотя им уже как для полного идиота сто раз рассказывали, что будем поднимать снова https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=189936&pg=23#2368556 ?
22 июн 06, 10:35    [2800620]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

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

А я и не говорил об АБСОЛЮТНОЙ надежности К\С СУБД! Я говорил о том, что то, что называют поддержкой DRI и транзакционной целостности в Ф\С и К\С СУБД суть две большие разницы.


Да не надо оправдываться. То абсолютная, то не абсолютная, то просто различается.

Да, различается. Не только в разных технологиях но и на одном и том же сервере с разными настройками. Именно поэтому нет ответа на вопрос:"Скажите, а какая СУБД сейчас самая лучшая?".
22 июн 06, 10:39    [2800643]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

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

представься, не видно в каких тредах ты участвовал и какие вопросы задавал.
22 июн 06, 10:41    [2800649]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну вот, опять началось - Фокс опять стал к-с системой с использованием dbf

Скоро будут крики о том, что можно фокс навесить на dbf и сделать это все вебсервисом/COM+ и т.д. и т.п. и работать тогда с этим централизованным якобы одним движком......
Это как в другом анекдоте: если бы у бабушки были яйца, она была бы дедушкой

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

Весело наблюдать все это

-- Tygra's --
22 июн 06, 10:42    [2800659]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
да вроде ни слова про это нет
22 июн 06, 10:48    [2800705]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
1024
автор

А я и не говорил об АБСОЛЮТНОЙ надежности К\С СУБД! Я говорил о том, что то, что называют поддержкой DRI и транзакционной целостности в Ф\С и К\С СУБД суть две большие разницы.


Да не надо оправдываться. То абсолютная, то не абсолютная, то просто различается. Да, различается. Не только в разных технологиях но и на одном и том же сервере с разными настройками. Именно поэтому нет ответа на вопрос:"Скажите, а какая СУБД сейчас самая лучшая?".


Я и не собирался оправдываться. Еще раз, для непонимающих разницу. То, что в Ф\С СУБД называется поддержкой DRI и транзакциями и рядом невалялось с действительно поддержкой всего этого в К\С СУБД. Тем, кто это непонимает, место на той же свалке. :)
22 июн 06, 10:56    [2800769]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
5631
Member

Откуда:
Сообщений: 452
.
22 июн 06, 10:58    [2800791]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
Я и не собирался оправдываться. Еще раз, для непонимающих разницу. То, что в MySQL называется поддержкой DRI и транзакциями и рядом невалялось с действительно поддержкой всего этого в MS SQL. Тем, кто это непонимает, место на той же свалке. :)

=============
8)

и MySQL и MS SQL являются SQL-серверами на 100% но изменённая цитата полностью им соответствует
22 июн 06, 11:21    [2800976]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 1024

То "винт полетел", то "MySQL". Я теряю Вашу мысль...
22 июн 06, 11:36    [2801081]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
H5N1
Guest
1024
2 H5N1

представься, не видно в каких тредах ты участвовал и какие вопросы задавал.

зачем, что это изменит ? если вы после всего сказаного в том топике не вьехали в элементарные принципы работы нормальных субд, то у вас диагноз ;)
22 июн 06, 11:40    [2801108]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
если у тебя в профиле вопросы вроде "как узнать номер первой записи в запросе" то и к словам твоим можно относиться соответствующе.
22 июн 06, 12:05    [2801318]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
не мне а менее начинающим
22 июн 06, 12:06    [2801327]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
H5N1
Guest
1024
если у тебя в профиле вопросы вроде "как узнать номер первой записи в запросе" то и к словам твоим можно относиться соответствующе.

ну да пришел тут какой-то, обосрал документацию, обосрал всех лисоводов, объяснил, что они 10 лет кодят не понимая простейших принципов работы фокспро (неговоря уже о КС субд), и еще скотина оказался прав.
ну конечно же это студент :) ну кто-ж еще так смело мог прийти и обосрать ?
22 июн 06, 12:30    [2801529]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
вероятно ты и окурки мимо урны бросаешь на улице.

8(
22 июн 06, 12:48    [2801634]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить