199 ответов в теме

[myst]

Вообще, создалось впечатление, будто в ССР не было человека, занимающегося архитектурой базы данных, а сейчас появился и начал править.

Как раз наоборот. Правки до того незначительные, что это скорее тюнинг. А из того, что я смог узнать об их БД, уж кто-кто, а DBA у них что надо. Что не отменяет того факта, что SQL Server -- говно(*), разумеется.

[intari]

Прочитал...

Мне одному показалось что все идентификаторы любых типов объектов существуют в пределах одного множества уникальных идентификаторов ? CCP не догадывается что имплантант в голове и партрон в трюме могут иметь один и тот же идентификатор - хранясь в разных таблицах БД ? На которые настроены разные индексы ? Вряд ли.

Что-то видимо перевод в первом посте неверный.

Перевод там правильный.

Если посмотреть код клиента - там даже куча мест есть где по попаданию itemID в диапазон прямо на клиенте определяется тип обьекта

Сообщение отредактировал intari: 26 October 2010 - 5:42

[yleo]

больше 2 бит на руки не давайте! Девушка! Куда вы без очереди?

[Psihius]

не думаю что в 2003 году были все такие умные и расчитывали на такие масштабы
к тому же рабочий принцип: "работает - не трожь!"

В 2003 384GB RAM было мечтой, сегодня обыденная реальность. Тогда память старались экономить, да и надобности небыло в 64 битных идентификаторах. Сегодня-же и онлайн насколько сильно вырос, и объёмы вещей, вот и необходим апгрейд. Главное что апгрейд безболезненный по своей сути, только базе нужно перемолотить обновление типа столбцов в таблицах и перестроить индексы соотвественно.

[dark angel66]

Лучше быть умным и иногда тупить, чем быть тупым и постоянно умничать!

ЗЫ а про ССР эт ты верно подметил... ССР без кастылей это не ССР вовсе

Сообщение отредактировал dark angel66: 26 October 2010 - 14:43

[Lantitudia]

Вопрос скорости. Если взорвется шип с импом и патронами, то сейчас надо будет выполнить один запрос в одной таблице (пускай и большой), а если импы и патроны будут в разных таблицах, надо делать два запроса или один более сложный. К тому же не факт что оптимально делить базу на таблицы по типа предметов, может по местоположению предмета было бы лучше.

Вопрос - то вопрос, и "не факт". Давно занимался оптимизацией запросов к БД.

Но если бы было однозначно выгоднее иметь один уникальный ид на все типы объектов - так была бы спроектирована любая БД. Я такого, в основном, не наблюдал.

Единственные исключения когда разные типы объектов разделяли общий ид:
1. Наследование. Ид на личность - разделяют иды сотрудников и клиентов.
2. Метапрограммирование - когда база строится под хранение заранее неизвестных типов объектов. Но нагрузки там... ого-ого. =)

[ононимъ]

может не 4, а 8?

Ну да

Что не отменяет того факта, что SQL Server -- говно(*), разумеется.

Не согласен

[Trimutius III]

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

Сервер на самом деле ещё во времена Quantum Rise был переведен на 64х-битную платформу (про это даже в Features написано), но к типам перменных это действительно никакого отношения не имеет, они могут хоть 256 хоть 1024 бита содержать, от этого мало что изменится, даже пример нетрудно придумать, потому что любой текст это на самом деле очень длинная переменная. Всё что вы набраете в чате содержит гораздо по 16 бит на одну букву, и в сумме являетяс одной большой переменной в итоге.

Сообщение отредактировал Trimutius III: 27 October 2010 - 2:55

[Lantitudia]

Сервер на самом деле ещё во времена Quantum Rise был переведен на 64х-битную платформу (про это даже в Features написано), но к типам перменных это действительно никакого отношения не имеет, они могут хоть 256 хоть 1024 бита содержать, от этого мало что изменится, даже пример нетрудно придумать, потому что любой текст это на самом деле очень длинная переменная. Всё что вы набраете в чате содержит гораздо по 16 бит на одну букву, и в сумме являетяс одной большой переменной в итоге.

Только поиск по иду в 1024 будет очень медленным. Или нужен 1024-битный процессор. Про такие пока не слыхал. =)

[grafibori]

64 бита - это хорошо! Всетаки лучше чем 32.

[JesDarkJewel]

Только поиск по иду в 1024 будет очень медленным. Или нужен 1024-битный процессор. Про такие пока не слыхал. =)

Расскажите мне как связаны битность переменной и битность процессора?
а попутно можете рассказать чем отличается 32-битный проц от 64-битного.
(может пока будете рассказывать найдете свою ошибку)

едит: очепятка

Сообщение отредактировал JesDarkJewel: 27 October 2010 - 9:09

[myst]

Только поиск по ID в 1024 бита будет очень медленным. Или нужен 1024-битный процессор. Про такие пока не слыхал. =)

Т.е. для текстового поиска Google использует >1000-битные процессоры? Google же быстро ищет, да? Так забавно, когда всякие дилетанты высказывают своё мнение, право слово.

[Anastasy]

Тем что сравнивать 64-битную переменную можно за одну операцию на 64-битном регистре, чего не скажешь о 1024. Думаешь почему прикрутили математический сопроцессор для плавающих чисел, хотя можно и сложить их на обычном процессоре в 6 действий а уж сколько они тиков занимают одному богу известно.

[Henshin]

В 2003 384GB RAM было мечтой, сегодня обыденная реальность

В 2003 может и мечтати о таком, а в 2010ом о 384 GB RAM никто и не смеет помыслить

[3BEPEB]

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

то есть тока в день обновления будут наблюдать... а потом полгода им будет пох


p.s. классный перевод если чо

[Psihius]

В 2003 может и мечтати о таком, а в 2010ом о 384 GB RAM никто и не смеет помыслить

Здрасте, посмотрите спецификации двухпроцессорных машин, почти везде щас запихать можно 384GB RAM, местами до 512 уже даже.