ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор СУБД для конкретной ситуации
25 сообщений из 25, страница 1 из 1
Выбор СУБД для конкретной ситуации
    #35179099
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Вообщем стоит сейчас такая задача: в ближайшие полгода перевести базу данных с Access на ... . Верхний менеджмент говорит- нужен MS SQL Server. Но хотелось бы вашего совета.
Переход на новую БД связан с увеличением объема работы отдела. В настоящее время все базируется на многодесяткомегабайтных .mdb файлах в которых хранятся основные таблицы. Проблема во первых в скорости работы- когда к базам обращается несколько пользователей, то все начинает тормозить. Несильно, секунд 10-15 занимает запрос на выборку, но раздражает.
Вобщем в силу указанных обстоятельств получено ценное указание- базу переработать (оптимизировать), перевести на новые рельсы.
Вот тут и возникает вопрос:
какая СУБД лучше в этом случае? Требования в общем такие:
1. Надежное и детальное разделение прав доступа
2. Возможность обработки нескольких сотен тысяч записей с приемлемой скоростью.
3. Возможность связывания внешних отдельных файлов
4. По возможности простота миграции с Access на новую СУБД.
5. И еще раз надежность защиты хранимых данных от НСД
как вы думаете, MS SQL Server наилучший выбор?
PS опыт работы маловат, но- много желания, старания и способностей :)
...
Рейтинг: 0 / 0
07.03.2008, 20:37
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35179115
apapacy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
apapacy
Участник
Для Выших объемов подойдет практически любая БД.
MS SQL - нормльный выбор. Я сам на таких объемах много лет юзал MSDE2000 (Release A).
База ни разу не ложилась. Винт пару раз летел - восстанавливалось из архива без проблем.
При использовании Acess при MSSQL ддополнительное преимуществл - можно работать
с MS SQL проактически как будто с mdb.
С другими серверами конечно связь тоже можно установить -- но это все же будет более трудоемко
(хотя и без больших проблем)
...
Рейтинг: 0 / 0
07.03.2008, 20:53
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35179144
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Спасибо :) значит направление взято верное. Особенно насчет простоты связки с Access и будто работы с mdb файлами.
Кому нибудь приходилось с таким переездом сталкиваться? Какие подводные камни обнаружили?
...
Рейтинг: 0 / 0
07.03.2008, 21:26
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35179446
109E8B26-44A5-4CC1-83B8-181D1B84
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
109E8B26-44A5-4CC1-83B8-181D1B84
Гость
Поиск по MSDN и Google поможет.

http://msdn2.microsoft.com/en-us/library/bb188204.aspx
http://support.microsoft.com/kb/128808
...
Рейтинг: 0 / 0
08.03.2008, 12:11
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180072
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Спасибо за ссылку! Почитал, понравилось как написано.
зы теперь наверное надо в другой подфорум переходить :)
...
Рейтинг: 0 / 0
09.03.2008, 16:36
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180264
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Программист-Любитель
Участник
Вдумчивая переработка MDB приложения в ADP проект может улучшить качество вашего решения.
Не знаю насколько большое ваше приложение, но полгода - кажется завышенным сроком для перевода.
...
Рейтинг: 0 / 0
09.03.2008, 23:19
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180271
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Программист-ЛюбительВдумчивая переработка MDB приложения в ADP проект может улучшить качество вашего решения.
Не знаю насколько большое ваше приложение, но полгода - кажется завышенным сроком для перевода.
ситуация осложняется тем что опыт по разработке БД- минимален, опыт работы с MS SQL как бы сказать ... _маловат_. А хочется сделать все по возможности красиво и гладко. К тому же очень высоки требования именно к _гладкости_ перехода, чтобы и травинка не шелохнулась ;)

и вопрос,чем переработка в ADP помогет? Дело в том, что прочесть то описание, стандарты и прочее смогу, но интересует именно стратегический совет общего характера. Заранее благодарю
...
Рейтинг: 0 / 0
09.03.2008, 23:44
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180295
109E8B26-44A5-4CC1-83B8-181D1B84
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
109E8B26-44A5-4CC1-83B8-181D1B84
Гость
Гладко - это постепенно, по отдельным табличкам(или группам табличек) с тестированием всех запросов

Если используется DAO - плавный переход на ADO, вынос VBA кода в хранимые процедуры.
При необходимости - оптимизация(passthru Query, View на сервере, присоединённые как таблицы)

P.S. эволюционный подход предполагает сохранение mdb формата.
P.P.S бывет и полгода нужно, когда база велика (на некоторые таблицы - по отдельному mdb файлу, таблиц,форм и запросов - сотни, интерфейсных баз - несколько и требуется непрерывность перехода)
...
Рейтинг: 0 / 0
10.03.2008, 00:40
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180447
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
PirX Программист-ЛюбительВдумчивая переработка MDB приложения в ADP проект может улучшить качество вашего решения.
Не знаю насколько большое ваше приложение, но полгода - кажется завышенным сроком для перевода.
ситуация осложняется тем что опыт по разработке БД- минимален, опыт работы с MS SQL как бы сказать ... _маловат_. А хочется сделать все по возможности красиво и гладко. К тому же очень высоки требования именно к _гладкости_ перехода, чтобы и травинка не шелохнулась ;)

и вопрос,чем переработка в ADP помогет? Дело в том, что прочесть то описание, стандарты и прочее смогу, но интересует именно стратегический совет общего характера. Заранее благодарю
я бы посоветовал взять на проект человека с опытом SQL Server и, возможно, Access. он сможет задать правильное развитие проекта в плане работы с СУБД (скажем, за месяц-два), а затем ваша команда сама доделает весь проект.
...
Рейтинг: 0 / 0
10.03.2008, 12:42
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180542
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
AAron, специфика такова, что стороннего человека не возьмешь, а в своей команде по SQL спецов с _глубокими_ знаниями нет.
Потому и срок выделен большой.
...
Рейтинг: 0 / 0
10.03.2008, 14:08
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180550
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
И мне кажется что-то сильно усложнён переход от MSAccess...
есть утилка batchaccess (пару месяцев назад на профильном форуме sql.ru подкинули)...
она выдирает структуру и данные из mdb файла.. в виде скрипта...
синтаксис (даты, пустые поля ...) в MSSQL и Access ОЧЕНЬ похож (я бы сказал такой же, но не уверен на 100), и наверно проблем с восстановлением структуры и залития данных возникнуть не должно...
ну может сменить очерёдность создания VIEW (если они друг от друга зависимы) и если есть синтаксические нюансы...

если приложение на Access и связь не через ConnectionString, а как-то прямо к таблицам, то на месте старой базы MDB, подкидываете базу с ссылками на MS SQL сервер (связь данных).... всё... теперь база MS SQL, приложение на Access работает...
и начинаете потихонечко переводить всё (логику) на сам MSSQL сервер из приложения... спрва все сложные запросы в виде view, потом хранимки... и.т.д... тут да, несколько месяцев будете воять..

если клиент на делфях, например, то ещё проще, меняете строку подключения и всё...
возможно также можно и с приложением на Access (к сожлению сам ничего не программил)

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

я так переводил базу с MSAccess на MySQL...
в добавок к batchaccess написал утилку, которая скрипт данных преобразовывла к другому виду...
ну даты вместо #13/02/2006# '2006-02-13'...
чуть в коде поменял вместо '<> NILL' на 'IS NOT NILL'
время решения вопроса - 6 часов, база была небольшая... но если бы на MSSQL переводил, то заняло бы 1 час
Вам, думаю максимум за 3 дня можно управитсья (перенос базы на MSSQL, не считая преписания логики)
сперва пробуете, боретесь с подводными камнями... как увидели что всё работает, учли нюансы, подправили клиента - на пол часа тормозите работу пользователей, чистите таблички MSSQL, обнуляете счётчики, и сливаете туда "свежую" базу, юзерам нового клиента - и все продолжаете работать
...
Рейтинг: 0 / 0
10.03.2008, 14:16
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180589
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Кифирчик, спасибо, думаю так и буду понемногу переводить базу. плюс еще добавляется другой вопрос, может быть даже и основной- перевести базу на новую структуру, чтобы максимально исключить возможные ошибки ввода и облегчить составление отчетов.
Тут прихожу к мысли что стоит сначала загнать вышеуказанным способом базы в MS SQL, а уже потом разрабатывать новую структуру БД. При этом всю работу оставить на старой логике. Новую же потихоньку клепать и клепать. И уже после окончательной проверки на ошибки (если такое возможно :) ), подготовив клиентские приложения разом перевести все на новье.
Как оцените план? На данный момент для меня это основной вопрос. Куда идти понятно, теперь думаю как идти к цели
...
Рейтинг: 0 / 0
10.03.2008, 14:40
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180665
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
PirXперевести базу на новую структуру, чтобы максимально исключить возможные ошибки ввода и облегчить составление отчетов
если вы переводите на новую структуру, то это смотря на сколько меняется ваша структура... возможно придётся и специально конвертер писать...
для отчётов... если у вас там всё нормализовано, то смысл переводить? даже если нет, то ведь сейчас работает? имеет ли смысл, чтобы выиграть пол секунды, кординально переделывать базу?
все плюсы полноценного, многопользовательского SQL сервера почувствуют все сразу (по сравнению с MSAccess)
потом, как я понимаю важно чтобы это сделать не разрывая "производственного" процесса...
по этому мне кажется, начинать пользоваться новой базой, и раздавать пользователям настроенного для неё клиента... это нужно делать быстро....
ИМХО переводите структуру на MSSQL как есть, тудаже пользователей (с исправленными клиентами), а уже потом думай над оптимизацией, и над переписанием логики... ведь надо ещё научиться писать хранимки для MSSQL :) а это время...
потом возможно получится разработать полностью новую систему
...
Рейтинг: 0 / 0
10.03.2008, 15:36
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180754
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Насчет смены структуры, действительно выигрыш в производительности на MS SQL по сравнению со старой версией будет наверное малозаметен. Тут цель больше:
1) по возможности исключить ошибки ввода
2) сделать более удобным составление отчетов (а то с left, right приходится много возится)

но конечно смущает возможное нарушение принципа 'работает? Лучше не трогай' :)
...
Рейтинг: 0 / 0
10.03.2008, 16:58
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180758
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Поправлюсь, выигрыш новой и старой структур баз на MS SQL :)
...
Рейтинг: 0 / 0
10.03.2008, 17:01
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180919
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
PirXAAron, специфика такова, что стороннего человека не возьмешь, а в своей команде по SQL спецов с _глубокими_ знаниями нет.
Потому и срок выделен большой.
я советую взять специалиста-консультанта по СУБД, а не по специфике Он будет помогать и направлять разработку, а не делать какие-то специфические для бизнеса вещи.

но смотрите, ходить по граблям в одиночку всегда интереснее
...
Рейтинг: 0 / 0
10.03.2008, 18:37
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35180983
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
AAron, к сожалению привлечение сторонних специалистов исключено :(
...
Рейтинг: 0 / 0
10.03.2008, 19:25
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35181559
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Программист-Любитель
Участник
Кифирчиксинтаксис (даты, пустые поля ...) в MSSQL и Access ОЧЕНЬ похож (я бы сказал такой же, но не уверен на 100), и наверно проблем с восстановлением структуры и залития данных возникнуть не должно...
Это не совсем так. Совсем не так. Большие сложные запросы надо переписывать аккуратно руками. Некоторые вещи в SQL не переносимы вовсе - использование в запросах вибиашных пользовательских ф-ий, например. Зато можно писать свои эскуельные ф-ии.
...
Рейтинг: 0 / 0
11.03.2008, 09:05
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35181562
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Программист-Любитель
Участник
PirXAAron, к сожалению привлечение сторонних специалистов исключено :(
Типовая патовая ситуация. Если бизнесу требуется решение задачи, но под нее нет (жалко) ресурсов. И рыбку съесть, и на ... сесть и штанишки не порвать.
...
Рейтинг: 0 / 0
11.03.2008, 09:07
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35182247
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
Кифирчик wrote:
> И мне кажется что-то сильно усложнён переход от MSAccess...
> есть утилка batchaccess (пару месяцев назад на профильном форуме sql.ru
> подкинули)...
> она выдирает структуру и данные из mdb файла.. в виде скрипта...
> синтаксис (даты, пустые поля ...) в MSSQL и Access ОЧЕНЬ похож (я бы

http://www.microsoft.com/sql/solutions/migration/access/default.mspx
SQL Server Migration for Access
Microsoft SQL Server Migration Assistant (SSMA) for Access is a tool for
migrating databases from Microsoft Access versions 97 through 2003 to
Microsoft SQL Server 2005. SSMA for Access converts Access database
objects to SQL Server database objects, loads those objects into SQL
Server, and then migrates data from Access to SQL Server.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.03.2008, 12:57
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35182258
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
http://www.microsoft.com/sql/techinfo/whitepapers/MigrAccessSQL2005.mspx
Guide to Migrating from Microsoft Access to SQL Server 2005

This white paper covers migrating Microsoft Access databases to SQL
Server 2005 and discusses the differences between the two platforms. SQL
Server Migration Assistant for Access (SSMA Access) is the best tool for
this type of migration; this paper tells you how to use it to mitigate
potential problems in database conversion.

Included in this document:

• Introduction

• Overview of Access-to-SQL Server 2005 Migration

• Migration Wizard

• Migrating Database Objects

• Table Migration Potential Problems

• Jet Syntax Potential Problems

• Functions

• Data Migration

• Conclusion

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.03.2008, 12:59
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35182547
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
За ссылки спасибо!
Если правильно понимаю, то на русском материала нет? Или это оригинальные статьи и это надежнее? Может быть имеет смысл перевести на русский и тут где нибудь выложить? Хотя б в виде реферата?

Или может не стоит изобретать велосипед?! :-?
...
Рейтинг: 0 / 0
11.03.2008, 14:16
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35182558
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
PirX wrote:
> Если правильно понимаю, то на русском материала нет? Или это
> оригинальные статьи и это надежнее? Может быть имеет смысл перевести на
> русский и тут где нибудь выложить? Хотя б в виде реферата?
Это оригинальные статьи (точнее - документ).
Если есть желание перевести на русский и выложить - я думаю, никто не
будет против.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.03.2008, 14:19
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35182796
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
2PirX
А что хоть у вас за программа? что автоматизирует?
любопытно стало:)
...
Рейтинг: 0 / 0
11.03.2008, 15:24
| Ответить | Цитировать | Написать  
Выбор СУБД для конкретной ситуации
    #35182873
PirX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PirX
Гость
Кифирчик2PirX
А что хоть у вас за программа? что автоматизирует?
любопытно стало:)
автоматизирует документооборот ;)

Кифирчик, ты по ходу правильно понял причину невозможности привлечения стороннего разработчика :D
...
Рейтинг: 0 / 0
11.03.2008, 15:43
| Ответить | Цитировать | Написать  
25 сообщений из 25, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор СУБД для конкретной ситуации
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=35179144&tid=1553153]:
 0ms
get settings:
 11ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 38ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 53ms
get tp. blocked users:
 1ms
others: 13ms
total:  148ms
созд. / загр.: 148ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]