|
|
| Тема |
 Re: Още масло в огъня...:) [re: тъп4o] |
|
| Автор |
salle (Един такъв) |
|
| Публикувано | 14.10.02 19:20 |
|
|
|
> ще е задължително
хмм... руснаците имат една хубава поговорка ...
> всичко това с мобилно устройство
А това пък какво общо има с XML?
> (идвам от M$ SQLServer/Oracle).
Ами тук е 90% от отговорът на всичките ти въпроси. Щом го правиш значи има за какво.
(И аз навремето "дойдох" от Oracle.  )
Сериозно обаче. За всяко едно от нещата за които кажеш, че MySQL не ги поддържа веднага стои въпросът:
А трябва ли ти? А на кой от потребителите и в какви случаи му трябва?
Този въпрос стои винаги - за всеки един софтуер и всъщност е определящ.
Пример от Windows. Използвам Notepad - ама не можел да сменя шрифтове и не разбирал от форматиране и не поддържал....
Е да де ама аз го използвам за да си редактирам autoexec.bat примерно. Или пък да си разпечатам бележка на която пише "Водомера ми показва 99999" и да я лепна на вратата за инкасатора.
С какво ще ми помогнат шрифтовете? Трябва ли да дам още XXX $ за да си купя MS Office само за да си свърша ТОЧНО ТАЗИ работа?
Хайде обратно. Правиш уеб сайт за някакво Списание. Списанието се обновява веднъж седмично и толкоз. Е за какво са ти транзакции? Ама нямало :) Ами трябват ли?
За XML-а - и четеното на документацията:
Току-що ми помогна да открия един пропуск - заминава към Doc отбора. Благодаря всъщност
т.е. глава 4.8.2 mysql, The Command-line Tool
казва
-H, --html
Produce HTML output.
а ако пуснеш mysql --help ще забележиш още една опция:
-X, --xml Produce XML output
каквото и да значи това
Пробвай - може пък да ти хареса. Ако не ти хареса пък кажи какво не ти харесва да го оправим. Или пък разгредай кода и го допиши - ако е добре направено ще влезе в дистрибуцията.
> а. Няма съхранени процедури - за сметка на бързината.
Засега. В 5.0 (ще) ги има. 5.0 още е в много ранен стадий на разработка.
> б. Подзаявки (subqueries)
Има във 4.1 - също ранен стадий, но вече публично достъпна.
ОБАЧЕ. За огромно мое съжаление 90% от критиките спрямо MySQL по повод на Подзаявките са от рода на:
Ми тази заявка не работи - начи MySQL е боклук.
Тази заявка се оказва:
SELECT a, b FROM x WHERE c IN (SELECT c FROM x WHERE d = 10);
или
SELECT a FROM (SELECT * FROM x WHERE i > 10) WHERE i < 100;
Изобщо аз винаги съм доказвал, че има случаи в които единствено Подзаявките решение и не могат да се препишат по друг начин. Сигурен съм, че и ти ще се сетиш за такива примери.
Огромната част от потребителите обаче реват за Подзаявки просто защото не знаят SQL.
И да им обясняваш и да не им обясняваш, че за един и същ резултат (ако е възможно) JOIN винаги е по бърз от Подзаявки никой не те слуша.
За производителността на временните таблици бих поспорил.
1. Защото такава таблица в MySQL можеш да я създадеш като TYPE=HEAP и да откриеш, че е адски бърза
2. Защото и най-хитрия оптимизатор не може да прецени винаги кой е най-добрия план за изпълнение. (а трябва да призная, че този на MySQL е далеч от съвършенството)
3. С временни таблици можеш да освободиш истинските таблици много по-бързо. Независимо дали става дума за заключване (locks - независимо от вида) или за версии (versioning, snapshots) и дали си във транзакция или не - тази техника може да ти осигури по-бърза реакция на системата.
> в. Foreign keys, Views - не толкова важни ама е хубаво да ги има.
Тук вече те хванах натясно.
Виждаш ли доколко персонално е всичко? Има много хора които поставят на първо масто като важност Views (аз влизам в тази категория) много преди Транзакциите.
Според други пък най-важното нещо са Stored Procedures + Тригери (а тях къде ги забрави? )
Иначе Foreign key се поддържат от InnoDB.
Тригери ... засега ги няма.
Views - не по-рано от 5.0 - по-вероятно в 5.1
> Освен това проблеми с:
> Репликация
Не те разбрах. За какви проблеми говориш?
> Автоматичния Repair на таблиците
Пак не разбрах. --myisam-recover ли говориш? (За тази опция не съм срещал оплаквания досега) Или за възстановяване на Innodb до Checkpoint при повредени на файлове?
> Clustered databases
За съжаление се оказа, че този термин е адски размит и всеки производител си го използва както му хареса.
> Innobase (Finland) - какво ще стане ако тия пичове спрат в един момент да го разработват...
Тия ... всъщност се "казват" Heikki Turri. Дал си е координатите човека. Защо не го питаш него по въпроса?
Ако му омръзне да разработва казваш. Ами помисли - InnoDB е с отворен код нали така? Значи?
Всъщност ако смяташ, че можеш да напишеш по-добър тип таблици - заповядай.
Тестове .... Аз пък съм против каквито и да било тестове. Просто защото тестовете са синтетични а при Базите Данни има само Частни случаи. Можеш да оптимизираш Конкретна база данни върху конкретен сървър за работа с конкретно приложение. И при тези условия да изтестваш няколко различни пордукта и да определиш, че във твоя случай A работи по-бързо от Б. Това обаче не означава, че в други условия Б няма да е пъ-добър.
Иначе ако ти е за Независими тестове - прочети това
Аз не бих използвал в реални условия такова приложение - но резултатът е, че при Поставени тези условия т.е. все едно дефинирани от потребителя ... можеш да прочетеш.
...и после да включиш цената в уравнението.
А ако наистина прочетеш внимателно статиято можеш да забележиш един "трик" в оптимизацията, който е уникален за MySQL
Това, че можеш да използваш различни типове таблици в една и съща БД, заявка, транзкция.
Ха си представи, че описваш Транзакция за която предварително знаеш, че включва 5 таблици но само една от тях ще се промени. Другите ги променяш 1 месечно или годишно или в много редки случаи (Представи си списъци на градовете, общините, реките в България ...)
А пък мойто ЕГН започва със 6405....
| |
| |
| 
|
|
