Opteron 150 vs. Xeon 3.6 Nocona

Данная новость уже пахнет. Хорошо, что ее хоть не дважды сообщили, как на linux.ru.net:

http://www.lrn.ru/index.php?module=news&action=thread&newsid=8921

http://www.lrn.ru/index.php?module=news&action=thread&newsid=8935

Ну что и следовало ожидать. Opteron порвал Xeon как тузик грелку.
Самый интересный тест был про то, как mysql оказался в десять раз
быстрее, чем постгрес ;) А говорили, что они типа почти одинаковы ;)

The first uses MySQLd 4.0.20d installed from x86_64 RPM; precompiled by the SuSE team.
....
Adding Postgres to the SQL benchmarks was fairly easy. Although this may not be the most optimized way to benchmark Postgres, our time was limited.
....
Remember, even though times are significantly longer in this benchmark, they do not show whether or not one database is faster than the other.

Postgresql трудно сравнивать с MySQL - на простых операциях не имеет смысла, а на сложных не возможно, т.к. в Mysql мало что из этого есть.

> Самый интересный тест был про то, как mysql оказался в десять раз быстрее, чем постгрес ;) А говорили, что они типа почти одинаковы ;)

Так они мускуль небось на MyISAM-таблицах гоняли, конечно, оно быстрее будет, в режиме DBF-фронтенда =)

mysql надо было сравнивать с плоскими текстовыми файлами....

grep быстрее mysql в 10 раз а по возможностям они одинаковы

Там кстати сказано, что в качестве компилятора использовался gcc 3.3.3, а если компилировать под gcc 3.4.1, то выигрыш на оптеронах может быть еще большим.

диагноз - ламер. ну я бы понял если бы sqlite написал. ты же даже не слышал - плаваешь в вопросе. а туда же. полез

> grep быстрее mysql в 10 раз а по возможностям они одинаковы

Аналог select products.name, vendors.name from products, vendors where products.vendor = vendors.id с использованием только grep в студию! :-)

Нда...Видать придется еще awk'a добавить. :)

MS SQL Grep engine. This is a developer tool designed to maintain and expand existing MS SQL databases.

> Так они мускуль небось на MyISAM-таблицах гоняли, конечно, оно быстрее будет, в режиме DBF-фронтенда =)

За оправдание не прокатывает ;) Если я из А в Б пешком добрался быстрее,
чем сосед на автомобиле, можно сколько угодно обсуждать кривизну моих
ног и красоту автомобиля соседа, но результат от этого не поменяется ;)

> grep быстрее mysql в 10 раз а по возможностям они одинаковы

На полнотекстовом поиске. Возможно. И то не во всех случаях. Но в тесте
он не использовался.

>Данная новость уже пахнет. Хорошо, что ее хоть не дважды сообщили, как на linux.ru.net

Это разные тесты: Athlon vs. Xeon, Opteron vs. Xeon - глазки протирать надо!

Судя по тестам на ixbt, процы Intel каждый раз с введением новых технологий работают все медленнее и медленнее...

>> select products.name, vendors.name from products, vendors where products.vendor = vendors.id

1) А так не проще:
SELECT A.name, B.name
FROM products A, vendors B
WHERE A.vendor = B.id

2) А вообще конкретно бесит дизайн систем, где PK и FK имеют разные имена. Почему нельзя в Products и Vendors иметь просто VendorID ???

3) Кстате где-то по теории имена таблиц должны быть в единственном числе: типа Продукт, Провавец, без вякиз -s наконце. Не знаю, кто там прав, но я кошу под Оракловские сист. вьюшки, которые s-экают: USER_TABLES, USER_TAB_COLUMNS, etc. Поэтому тоже люблю Products, Providers, Lists, Blocks, Rubrics, etc.

>linux.ru.net

спалить жалкий клон лора! таким выдающимся, объективным и умным этот сайт не будет никогда!

> Если я из А в Б пешком добрался быстрее, чем сосед на автомобиле, можно сколько угодно обсуждать кривизну моих ног и красоту автомобиля соседа, но результат от этого не поменяется ;)

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

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

Увы, и это не оправдание ;) Забыл, потерял, не смог, не знал - это
никого не волнует. Важен только конечный результат ;)

> Увы, и это не оправдание ;) Забыл, потерял, не смог, не знал - это никого не волнует. Важен только конечный результат ;)

...угу. Но при этом шёл мокрый снег с дождём и был сильный ветер.

> Увы, и это не оправдание ;) Забыл, потерял, не смог, не знал - это никого не волнует. Важен только конечный результат ;)

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

> А так не проще: SELECT A.name, B.name FROM products A, vendors B WHERE A.vendor = B.id

А за такое можно и убить - особенно если в запросе объединяется более 5 таблиц. Введение неосмысленных алиасов практическ мгновенно "убивает" читабельность запроса, как только количество таблиц перевалит 5-7 (точное количество зависит от человека).

> А вообще конкретно бесит дизайн систем, где PK и FK имеют разные имена. Почему нельзя в Products и Vendors иметь просто VendorID ???

Вопрос стиля. Меня, например, очень раздражает, когда "синтетические" внешние ключи (типа того самого ID) в разных таблицах имеют разные наименования. Ты еще предложи, например, в паре таблиц country и city поле наименования назвать CountryName и CityName...

P.S.: не нравятся наименования таблиц - одень на них представления со своими именами, какие проблемы? На план выполнения запроса это все равно не повлияет :-)

>>А за такое можно и убить
Лучше убей себя, либо того, кого ты любиш. Нахрен здесь нужны осмысленные алиасы? Я лихко пишу запросы с объединением до 5-7 таблиц и нифига не путаюсь. Может я uber-programmer?

>>Ты еще предложи, например, в паре таблиц country и city поле наименования назвать CountryName и CityName

А давай неебаться и все ид во всех 500 таблицах так и назавем: ID!!!
А?

>>представления

вьюхи для этого рулят, согласен.

> Ладно, уговорил. Можешь ходить пешком и дальше, раз у тебя это всегда быстрее получается.

Ладно, уговорил. Можешь ездить на машине и дальше, даже если твою
машину обходят пешеходы ;)

Я бы скорее сравнил использование MySQL с поездкой на велосипеде. Вот этом: http://www.gazeta.ru/sport/2004/08/kz_150385.shtml?kz150385

Ну, велосипед - это вообще роскошно! Весь Китай на велосипедах ездит и
никто не жалуется.

> Я лихко пишу запросы с объединением до 5-7 таблиц и нифига не путаюсь

Ок. А теперь маленькая задачка - выбрать составить отчет о приходе на склад, в котором надо всего-то собрать: договор, отсрочку платежа по этапу договора в соответствии с которым произведена поставка, номер и дату накладной, по которой принят товар, его цену и описание, наименование склада принятия, вид траспорта и идентификационный номер транспортного средства, контрагента-поставщика и контрагента-грузоотправителя.

Есть таблицы: накладные, спецификации накладных, договоры, этапы договоров, складские операции, товары, модификации товаров, группы товаров, упаковки товаров, контрагенты, виды транспорта, транспортные средства, склады, единицы измерения.

И как насчет пятнадцати однобуквенных алиасов? А насчет разобраться в запросе через полгода? А если еще и парочку вложенных запросов? Ты, похоже, ничего сложнее "Автоматизированного рабочего места <<Деканат>>" не писал :-)