MySQL vs MS SQL

Ага, а когда база разрастется до энного количества гигабайт, клиента застрелить ?

Miha Kuzmin (KMY), Ага, только и остается!

Interitus Леш, я видно не совсем адекватно описал ситуацию. Есть клиент - система магазинов, разбросанная по разным штатам. Им нужен сайт - этой самой системы магазинов. Еще у этой компании есть другая система магазинов, под другим названием. Есть еще и третья.

То есть на одной базе данных будут сидеть три разных сайта, трех разных магазинных сетей, но принадлежащих одной компании.

Далее. Каждая из систем магазинов будет иметь энное количество самостоятельных сайтов, посвященных только одной теме. Например - продажа корма для кошек и собак. Другой сайт посвящен товарам другой секции магазина - скажем, продажа школьных принадлежностей. Третья секция - "все для суши" на своем отдельном сайте продает васаби, все эти водоросли, бамбуковые палочки, специальный рис и т.д. Таких узко специализированных сайтов будет сколько-то. Может 20, а может и 120. Это будущее. Но они тоже сидеть будут на той же базе.

Система управления контентом - на отдельном домене. Вводить товары в базу будут работники разных (географически) магазинов, разных сетей. Соответственно разграничение в уровне доступа - у каждого к своему разделу.

Обрабатывать заказ и отправлять товар покупателю будет тот магазин, который ближе к покупателю географически. Покупатель из Бостона получит товар из Нью-Йорка, а в Сан-Диего отправят из Лос-Анджелеса. Но если на складе в Лос-Анджелесе в конкретный момент времени товара не оказалось, отправят из ближайшего места, где он есть - например, из Аризоны. То есть единая база и для управления складом, с разграничением уровня доступа исполнителей.

Далее - там же вся статистика, бухгалтерия, квикбукс и т.д.

Предположительно в сутки будет 10-15 тысяч трансакций, а может быть и больше.

Сразу вопрос - можно ли такую базу держать на одной однопроцессорной машине? :) А на одном хостинге? То-то и оно. Если ляжет, то вся сетка сайтов одновременно накроется. И сервера должны быть хотя бы двупроцессорные, да и кластерная система желательна.

А это как раз те моменты, где MySQL не самое оптимальное решение. Если еще к этому добавить не совсем ясное будущее - там какие-то проблемы с лицензиями грядут? Или я что-то путаю? :)

У MS SQL есть готовые решения и по кластерам, и по многоуровневому доступу. То, что за лицензии надо платить - в данном случае проблемы не составляет, торговая сеть себе это может позволить. Нет и проблемы FreeBSD, сайт изначально прописан в ASP.NET и затачивался под Майкрософтовские сервера.

В такой ситуации, на мой взгляд, выбор SQL более предпочтителен. Теперь это все внятно надо бы до клиента донести.

С уважением,

Виктор

Стоп, стоп, стоп. Судя по данным утверждениям, твое решение неправильное. Из соображений безопасности, производительности и т.д. у тебя должна быть одна база, обслуживающая онлайн-транзакции (OLTP), и вторая - для всего остального. Если тебе станет легче - подобный вопрос в ходит в сертификационный экзамен MS для разработчиков БД :)

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

Тут часто появляется возражение, а если товар в прайсе есть, а на складе его нет? Будут неприятности. Неприятности как раз возникают при одновременных конкурентных выборках из таблицы и одновременных изменениях записей в этой же таблице. Т.е. что получается: запрос на изменение данных сначала ждёт, пока ему освободят страницу данных, где он будет проводить изменения, а потом все ждут пока он закончит проводить изменения. Если запросов на изменение мало, то ничего страшного. А вот если много, то будут выстраиваться огромные очереди запросов. Особенно если к простым запросам от клиентов добавятся тяжеловесные запросы от бухгалтеров и прочих манагеров. Проблема решается наращиванием компьютерных мощностей. Но всегда есть риск уткнутся в потолок. Так что лучше делать разделение. Что же касается неприятностей с отсутствием товара на складе при наличии в прайсе, то данная проблема решается административными мероприятиями. Есть такой термин в нашей бухгалтерии: "неснижаемые складские запасы". Т.е. в прайс, изменяемый раз в сутки, попадают те товарные позиции, которые заведомо не будут проданы за один день.

Так вот, OLTP база может вполне обслуживаться и mySQL. Твой аргумент - гомогенность.

P.S: я немного утрировал ситуацию, т.к. множественные запросы к одной и той же таблице на изменение данных и на чтение можно разрулить, допустив грязное чтение данных, т.к. всё равно пока клиент оформляет свой заказ картина мира несколько раз изменится, но вот тяжеловесные запросы (OLAP, online analytical processing, т.е. сбор аналитики за большие промежутки времени, которые по определению не допускают грязного чтения) точно твой магазин введут в ступор, если будут выполнятся на OLTP базе.