Які причини все-таки використовувати SQL Server 2000?

З питань, що стосуються StackOverflow та інших країн, я помічаю, що все ще є люди, які використовують SQL Server 2000. Якщо чесно, найбільший вплив на мене полягає в тому, що я маю пам'ятати, як ми раніше робили речі без загальних табличних виразів.

Однак я хотів би знати, чи є фактичні причини (крім того, що "це не зламано") все-таки використовувати SQL Server 2000. Наприклад, я знаю, що є люди, які повинні використовувати .NET 1.1, оскільки вони мають підтримувати Системи Windows 2000. Чи є подібні, практичні причини, щоб не оновити систему SQL Server 2000 до SQL Server 2008 або 2005?

Ділова думка зазвичай сильно відрізняється від вашої. Навіщо використовувати щось нове, якщо воно не принесе більше прибутку, а лише витрати (міграція, перепідготовка тощо)?

Найкраща причина, на яку я можу подумати, - це варіант "він не зламаний", який виглядає так: у вас є бізнес-додаток, який працює з SQL 2000, але генерує помилки з SQL 2005. Це може бути не правильним пріоритетом для вашої організації в цей час відкрити капот для цього додатка (який не зламався) і змусити його працювати з новою базою даних.

Підтримка спадщини

SQL Server 2005 не повністю сумісний з SQL Server 2000. Аналітичні служби мають основні несумісності. Перехід до SQL Server 2005 має ненульову вартість від тестування регресії та перенесення. Багато організацій не потребують переїзду, тому вони не рухатимуться, поки не стануть необхідними.

Більшість постачальників СУБД (включені MS) підтримуватимуть версію СУБД протягом 10 років або більше - що довше, ніж у більшості інших типів програмного забезпечення. Якщо ви схрестите їх долоні зі сріблом (у достатній кількості), вони також укладуть конкретні договори, щоб продовжити підтримку на конкретній версії, довшій за неї.

Інші причини дотримуватися старіших версій насправді зумовлені конкретними обставинами, такими як уникнення відомого запущеного випуску (наприклад, MySQL 5.1 або pre-SP3 SQL2000) або проблеми з сертифікацією чи сумісністю.

Ведення виробничої бази даних SQL Server 2000

Для операційної системи, яка працює і перебуває у зрілій фазі свого життєвого циклу, не відбувається багато великих змін, мабуть, немає вагомих причин для оновлення до того, як СУБД не вийде з основної підтримки. Однак ви повинні планувати впорядкований шлях оновлення для цієї подій. Oracle досить відомий тим, що підтримують виробничі системи за давніми версіями.

SQL Server 2000 наближається до кінця свого життя, тому ви не хочете робити нові роботи над розробкою. Однак виробнича заявка повинна підтримуватись із планом, коли потрібно буде переходити. Ймовірно, у вас буде перезапис на руках, якщо ваш додаток написано на VB6 або класичному ASP - але це інша проблема; -}.

Справа зустрічна

Якби у мене був проект greenfield, я зазвичай рекомендував би останню версію платформи СУБД просто тому, що вона надає вам найдовше вікно підтримки постачальника. Ніхто не повинен мати SQL Server 2000 як корпоративний стандарт для нових проектів - EOL занадто близько. Для нового проекту це, безумовно, найсильніший аргумент для переходу до нової версії. Аргументи щодо економії грошей не тримають води; додаток понесе зайві витрати на перенесення протягом декількох років, якщо ви почнете працювати з SQL2000 зараз.

Ключовим моментом роботи на грінфілді є те, що надмірно консервативний вибір скорочує термін служби програми до того, як буде потрібно оновлення. Зазвичай хочеться, щоб конкретна причина не переходила на поточну версію платформи СУБД.

Ми не оновлюємо, оскільки у нас є фінансове програмне забезпечення, яке покладається на нього, і постачальник лише думає про підтримку цього нового "SQL 2005", про який останнім часом слухають блог божевільних дітей.

Чесно кажучи, мені боляче , що є суміш речей для підтримки, але це не так сильно, як це зашкодить усім у компанії виникнути проблеми з фінансовою системою, а потім мати, щоб постачальник фінансового програмного забезпечення вказав на нас і сміємось, коли ми звернулися за допомогою і зазначили, що проблеми почалися з моменту переходу на SQL 2005 до того, як вони його ратифікували.

Можна також сказати багато про те, щоб не виправляти речі, якщо вони насправді не зламані. Я хочу коли-небудь оновити всі свої SQL-сервери до 2008 року ... Я справді це роблю. Але я можу зробити багато іншого, що насправді покращує суть бізнесу таким чином, щоб зрозуміти і оцінити моїм менеджерам та користувачам ... ну це завжди буде першим.

У своїй відповіді на відповідь Mastermind ви згадуєте розробників, яким не подобається працювати з SQL 2000. Я підозрюю, що один із способів боротьби з цим був би той, який застосували б мої начальники, якби я вирішив, що мені "не подобається" підтримку SQL 2000: "Дякую, що ви працювали тут, двері зліва". Зрештою, нам всі платять за те, щоб роботи працювали, подобається нам це чи ні.

У нашому випадку це менш випадок "чому продовжувати використовувати 2000", ніж у випадку "оновлення коштує СТОЛЬКО?". Більшість наших додатків не використовують нічого, що потребує будь-яких особливостей 2005 року, тому немає вагомих причин і, мабуть, не буде, поки Microsoft не припинить підтримку.

Вартість.

Більш нове програмне забезпечення - це все-таки додаткове програмне забезпечення, яке коштує додаткових грошей.

Це може бути і часто є помилковою економією через безліч сторін використання застарілих систем, але це єдина реальна причина, яка має сенс.

Нова ліцензія на SQL Server 2008 (стандартна) коштує трохи менше 2000 доларів на 1 сервер з 5 ліцензійними ліцензіями або 6 000 доларів за 1 ліцензію на процесор. Я чую, як мій старий начальник говорив, що "це не зламалося, але це коштуватиме, скільки оновити ці два сервери?" (на той час 2 x подвійний процесор, що вимагає ліцензій на процесор).

Використовуючи SQL2000 протягом семи років, мій перший досвід 2005 року був у середовищі VMWare ESX. Працездатність виснажена (провайдер надав досвід VMWare, і коли ми розпочали тестування завантаження, ми виявили, що у них виникають серйозні проблеми не лише з нашим сервером, але вплинули на наш досвід), і поєдналися з усім, що пересувалося / перейменовувалося (старий менеджер підприємства був sooo набагато швидше) - ми були щасливішими відкласти оновлення. Тоді ми чекали виходу 2008 року, тому ми лише зараз переходимо до 2008 року (або переносимо деякі дані на MySQL / PostgresSQL).

Microsoft все ще надавала основну підтримку в 2000 році до певного часу минулого року, тому лише нещодавно у нас з'явилися більш вагомі причини для оновлення.

Невеликі компанії також мають проблеми з ресурсами - навчання, планування, тестування оновлення вимагає часу та впливає на інші операції. Якщо вам доведеться оновити якусь іншу програму, яка одночасно сидить на SQL Server, це також може бути дуже дорогим.

Деякий час ми загравали з переходом до відкритого коду, і, хоча це було можливістю, він також поставив заморозку на будь-яке оновлення.

Чому б не модернізувати до sql сервера 2008, тоді ви насправді можете знизити вартість завдяки компресії даних, більш легкому обслуговуванню та покращенню продуктивності (відфільтровані індекси)? Нещодавно ми оновили встановлення sql-сервера 2000 і заощадили 75% дискового простору, а продуктивність різко зросла.

Ще одним поліпшенням стала паралельність завдяки новому механізму блокування, введеному на сервері sql 2005 року.

/ Хокан Вінтер

Великі організації ризикують несприятливими та неосвіченими, що призводить до деяких дійсно тупих рішень. Коли я робив речі з Unix близько 2003/2004 року, ми застрягли із середовищем Solaris 2.5.1, яке було випущено, коли я навчався в 10-му класі або тому, що це "перевірена" технологія і це було "занадто дорого" для оновлення.

Занадто дорого часто говорять PHB за те, що "я був нерозумним до бюджету на оновлення 1000 доларів у проекті на 10 мільйонів доларів".

Що стосується програмного забезпечення для стека Microsoft, люди часто негативно впливають на оновлення, оскільки вони не хотіли мати справу з ліцензійним тролем у компанії та придбали ліцензію OEM від Dell / IBM / тощо, і не хочуть мати справу з бюрократичні обручі, що беруть участь у модернізації.

Я не купую (каламбур) аргумент "випереджаючої вартості", але, на жаль, передові витрати - це те, на що багато PHB переймаються, тому це дійсно, щоб воно стояло.

Для мене єдиною вагомою причиною були програми, які цим користуються. Якщо ви, наприклад, будинок SharePoint 2003, немає жодного способу перейти до SQL 2005 або 2008 року, не також здійснюючи оновлення SharePoint, що не є дрібницею.

В нашій організації вся нова розробка повинна бути на SQL 2005/2008, але у нас є стільки застарілих 2000 додатків, що просто не варто витрачати час / енергію / гроші на їх перетворення.

На додаток до питань сумісності (для нас найбільшим є DTS до SSIS), ми також застосували набір вказівок / обмежень безпеки для SQL 2005, які ми не застосовували для SQL 2000. (немає користувачів dbo, лише дозволи схем, тощо)

У нашої організації є кілька причин. Деякі з них досить специфічні для нашого випадку, а інші трохи більш загальні.

1) Несумісність. У нас було декілька випадків, коли програмне забезпечення, яке було написано для власного SQL2005, має проблеми при установці на SQL2000. Випадок, який я бачив останнім часом, пояснювався тим, що явно оголошено параметри, які не існують у 2000 році, та різницею в назві таблиці системних індексів. (sys.indexes vs sysindexes)

2) Навчання. Наші розробники, безумовно, знають 2005 рік, і вважають за краще розвиватися на ньому, або 2008 рік. Однак робота з утримання всього функціонування падає на НОК, а не на розробників. Ніхто в нашому НОК не проходив офіційного навчання SQL, і відмінності між ними, лише з точки зору адміністративного інструменту, є достатніми, щоб це врахувати.

3) Вартість модернізації існуючої продукції. Для нас це велике. Я не кажу тут про вартість ліцензії від Microsoft. У нашому бізнесі оновлення будь-якого з наших існуючих продуктів (навіть якби ми не модернізували все, що вже було в цій галузі) вимагало дорогого і тривалого процесу переатестації через декілька різних регуляторних та сертифікаційних тестових лабораторій. Ми будуємо нові продукти на SQL2005, але не модернізуємо старіші з цієї причини.

Процес сертифікації також означає, що ми отримаємо суміш з нових збірок, де певні юрисдикції отримуватимуть SQL2000, а інші отримують SQL2005, виходячи з того, були б отримані схвалення чи ні. Ми вважаємо за краще №2 підтримувати наше виробниче середовище максимально послідовним.

4) Загальні відмінності. Це дійсно розширення №1. Є багато дрібниць, які змінилися, деякі з яких викликають у нас головний біль. Наприклад, SQL2005 на Server2003 буде застосовувати політику паролів Windows для акаунтів sql. Сама по собі непогана річ, але вона зламає майже все наше (і багато іншого) програмне забезпечення через спосіб взаємодії з базою даних.

Словом, по інерції.

Хороший пост блогу , який вже поставив те ж питання.

Я знаю, що є люди, яким доводиться використовувати .NET 1.1, оскільки вони мають підтримувати системи Windows 2000.

Виходячи з цієї логіки, то практична причина для запуску MSSQL 2000 полягає в тому, що ви можете підтримувати системи Windows NT 4!

Вірите чи ні, але SQL Server 2005 насправді працює на Windows Server 2000.