Повод за размисъл

В тази статия
[линк]

Michael M. Gorman задава доста интересния въпрос (или по-точно това е заглавието)

IS SQL A REAL STANDARD ANYMORE?
или SQL вече стандарт ли е аджеба или що?

salle.online.bg/sig

и никога няма да стане
винаги големите ще натискат за "подобрения" или специфични случай или нещо подобно....


от друга страна - стане ли стандарт това означава, че развитието е спряло...

Все пак прочете ли статията?

Авторът е ватре в нещата по стандартизирането още от самото начало т.е. от Април 1978

Michael M. Gorman - Whitemarsh Information Systems, Corp.
Secretary - ANSI (American National Standards Institute) NCITS (National Committee on Information Technology Standards) H2 Technical Committee on Database

salle.online.bg/sig

Имах търпението да я изчета цялата статия...
1.Все пак стандартите не са задължителни (особено в програмирането) - те са препоръчителни. Добавянето на допълнителни функции при реализацията на конкретна RDBMS е с цел улесняване на потребителите (програмисти, администратори) на този продукт. Но все пак трябва минимума от стандарта да бъде включен при реализацията на конкретния RDBMS и едва тогава да се разширява - но за съжаление поради ограничения на архитектурата това невинаги е възможно...
2. Че на този пазар (на RDBMS) ще останат само няколко играчи е ясно на всички - и в другите сфери на икономиката произтичат подобни процеси на oкрупняване на бизнеса...
3. Това че вече NIST (National Institute for Standards and Technology) не извършва тестовете на различните RDBMS наистина не е добре (не че на някой в България му пука за това - в държавната администрация на БГ сигурно са внедрени всички възможни видове СУБД - като половината от тях са пиратски).
Сега всеки може да си прави тестове и да оборва конкуренцията, че неговия продукт е по-добър (Например Oracle не признава резултатите от тестовете на независими организации, а само неговите)...

Изобщо бъдещето на SQL е доста мътно, особено с развитието на XML..

който плаща той поръчва музиката....

пиша често в клуб фотография, там канон и никон са като левски и цска....
ясно ти е...

за едно и също нещо (например бързина на автофокус) което на пръв поглед може лесно да се измери различни независими тестове дават двата крайни противоположни резултата....а уж са независими....

преди време получих писмо от приятелка....почти колкото тая статия дълго беше...
върнах и го с молба за резюме....

добре, че детето има прекрасно чуство за хумор....

чакай малко, кво общо има тук XML??? не съм чувал и не мисля че име смисъл XML да се използва за извличане на данни от RDBMS.

Ima si. Polzvash XPath (ili XQuery ili tam kakvoto ti realizirat), to vatreshno se konvertira kam SQL ili tam kakto bazata si predstavia uery-tata, izpalniava se i ti se izpluva XML-sko. I nimash povtariashti se danni v joinovete. Samo deto za da mine vsichko prez text ... proizvoditelnost niama da komentirame

НЕ МЕ ЕБЕ КАК Е ВУТЕ, АЗ ГЛЕДАМ ДА СЪМ ДОБРЕ

Do kolkoto razbrah ot statiata v momenta vsichki bazi conformvat samo na entry level standarta na SQL. T.e. realno poglednato samo toi e standart, a drugite niva sa si bezsmisleni shtoto nikoi ne comformva na tiah.
Dali tova e losho? Neka da poglednem edin drug 'standart' (ili po-tochno grupa standarti)- OSI modela za mreji. Toi ima 8 niva kato na vsiako ima grupi standarti koito se implementvat. No kakvo stava v dneshno vreme - parvite 3-4 niva sa implementnati v populiarni standarti kato TCP/IP i ATM. Dokato za po-gornite niva (application, presentation) nito ima adekvatni standarti koito da se polzvat, nito pak v resheniata koito se predlagat mogat da se otdeliat tezi niva. Primer: niakoi bi li mi pokazal v edno moderno prilojenie s web front-end kade mu e applicationa i presentationa v smisala na OSI? T.e. standarta se polzva do niakade i e mnogo uspeshen, a ostanalata chast ot nego ne se polzva.
Vse pak po-gornite niva na standarta vse oshte sa polezni - te davat guideline na vendorite kak da realizirat razlichnite featuri. Te moje i da ne implementnat srednoto nivo na SQL-a, a samo 20% ot nego, no ako go napraviat taka che da saotvetstva na standarta ili po podoben nachin, pak ima polza.
I nai nakraia da popitam kakvo e znachenieto i kakva e polzata ot standartite? ECMASCRIPT i HTML praviat li web stranicite prenosimi? Ne e li po-dobre vmesto standarti da ima niakoi kato SUN koito da poddarja Java i da licensira, i koito se otkloni malko i mu se reje glavata?
I nakraia poneje ti postvash temata da popitam - MySQL na koia versia na SQL standarta otgovria? Testvan li e predi 96 godina ot NITS (ili kakto tam beshe sakrashtenieto)?

НЕ МЕ ЕБЕ КАК Е ВУТЕ, АЗ ГЛЕДАМ ДА СЪМ ДОБРЕ

ми ти сам го каза - щом няма да коментиравме производителността, това автоматично ни спестява коментирането на приложението на тази технология в конкретния случай

Savsem ne. Predstavi si slednite sluchai:

- mobilni devici razpolagat s prilojenia koito imat sobstven snapshot na chast ot bazata i praviat replikacia kogato devicata se svarje kam internet. replikaciata stava po HTTP sas SOAP. Ne e li po-dobre da si poluchish gotov XML ot bazata?
- tvoeto prilojenie ima HTML frontend, kato izpolzvash XSL za generirane na stranici. Ne e li po-dobre da si poluchavash dannite gotovi v XML vmesto da bichish DOM-ove kato lud?
- pravish backend za sistema za reservacii na koli pod naem. backenda shte se polzva kakto ot websaita na firmata ti, taka i ot drugi sistemi prinadlejashti na aviokompanii, hoteli, turisticheski agencii. Komunikaciata shte stava prez SOAP. Resheno e che edna reservacia shte predstavliava XML dokument. Ne e li po-dobre ako bazata moje da ti varne XML direktno vmesto ti da go sglobiavash ot recordseti?

Vsichki tezi sluchai sa savsem realni i vzeti ot praktikata. I ochevidno e che za reshavaneto na problemite edna baza 'razbirashta' XML e samo dobre doshla.

НЕ МЕ ЕБЕ КАК Е ВУТЕ, АЗ ГЛЕДАМ ДА СЪМ ДОБРЕ

Защо ми се струва, че бъркаш понятията "Данни" и "База Данни"?

И по-конкретно май не правиш разлика между "Съхраняване на Данни" и "Данни във База Данни". Ако разглеждаш БД като хранилище на данни с единствена задача да "извличаш" данни от нея - просто не ти трябва БД ИЗОБЩО - това е типичната задача на една Файлова Система за което Файловите системи са оптимизирани. БД са за друго.

salle.online.bg/sig

И по-конкретно май не правиш разлика между "Съхраняване на Данни" и "Данни във База Данни".
Kakva tochno razlika imash vpredvid?

Ако разглеждаш БД като хранилище на данни с единствена задача да "извличаш" данни от нея - просто не ти трябва БД ИЗОБЩО - това е типичната задача на една Файлова Система за което Файловите системи са оптимизирани.
Failovata sistema sahraniava failove. Az govoria za hranilishte na 'obekti' v nai-obshtia smisal na dumata. Edna baza danni moje da ima SQL (ili drug relacionen) interfeis, obekten interfeis (primerno ima razshirenia za relacionni bazi danni da izglejdat kato obektni), XML interfeis. Badeshita Yukon primerno shte ima interfeis na failova sisterma (NTFS). Govoria vse za programni interfeisi. Ta misalta mi e che ako tvoeto prilojenie raboti predimno s XML, to e gotino samata baza da moje da sahraniava i izvlicha XML, vmesto ti parvo da minavash prez neshto kato ADO/ODBC/JDBC i posle sam da si pravish ot recordsetite XML. I obratnoto pri zapis.

БД са за друго.
Kakvo?

НЕ МЕ ЕБЕ КАК Е ВУТЕ, АЗ ГЛЕДАМ ДА СЪМ ДОБРЕ

Всичко това много добре.
Обаче няма нищо общо с темата, която подхвърлих. Ставаше дума за ANSI SQL не за обвивки на SQL-а или за алтернативни интерфейси.

Все пак SQL е език за работа с Релационни Бази Данни. Обектните са съвсем друга област.

salle.online.bg/sig

Брей, изядохте човека - май само Perin разбра какво имам предвид. Добавянето на XML-support при реализацията на дадена DBMS (M$ са се опитали в SQLServer2000, ама много бъгаво...) ще е задължително след време, най-вече заради Web-developers (нe знам дали ще има такова понятие като Database-programmer - след време) - след време, след време - ама след колко точно - никой не знае...Администриране на БД, обработка на данни, въвеждане на данни - всичко това с мобилно устройство в ръката (докато лежиш на плажа в Маями с някоя руса негърка:))...Като и да е XML e голяма тема и тепърва ще се развива...
Нека се върнем към MySQL и съвместимостта му с Ansi SQL! Това поне за мен е много интересно, защото аз нямам опит с MySQL (идвам от M$ SQLServer/Oracle). Та за 3-ти път препрочитам документацията на MySQL (сигурно заради ЕГН-то) и какво пише там във връзка с ANSI SQL:
1. Поддържа се само EntryLevel SQL-92, ама в следващите версии стремежа е към пълна поддръжка на SQL-99 :)(изобщо документацията прилича малко на рекламна книжка, ама пак е добре че я има:)).
2. Това, което се поддържа май е по-малко от това дето не се поддържа:):
а. Няма съхранени процедури - за сметка на бързината.
б. Подзаявки (subqueries) - някой ще каже "Не е важно, защото ще използваш Temp-таблици" - да де ама и 10 Temp таблици не помагат в някои случаи - да не говорим как се отразява това на производителността.
в. Foreign keys, Views - не толкова важни ама е хубаво да ги има.

Освен това проблеми с: Репликация, Автоматичния Repair на таблиците, Clustered databases...
Друг проблем е това, че истинския тип таблици, който единствен поддържа транзакции (InnoDb) не е дело на MySQL AB, а на друга компания Innobase (Finland) - какво ще стане ако тия пичове спрат в един момент да го разработват...То досега беше и невъзможно да се правят разумни тестове с MySQL, защото не поддържаше транзакции, т.е. понятието транзакции/мин нямаше как да се провери (изпълняването на прости Select-заявки дори и над милиони записи не е критерий).
Все пак някой да не помисли, че не съм фен на MySQL - напротив, след като на стари години взех да го уча:) Всички гореизброени недостатъци се игнорират от факта, че е безплатен (или условно безплатен), т.е ако вземем предвид критерия брой транзакции/мин.$ - когато делиш на число близко до 0 (т.е. 0 USD) - тогава резултата е без конкуренция (дори и броя транзакции да е малък).

> ще е задължително
хмм... руснаците имат една хубава поговорка ...

> всичко това с мобилно устройство
А това пък какво общо има с XML?

> (идвам от M$ SQLServer/Oracle).

Ами тук е 90% от отговорът на всичките ти въпроси. Щом го правиш значи има за какво.

(И аз навремето "дойдох" от Oracle. )

Сериозно обаче. За всяко едно от нещата за които кажеш, че MySQL не ги поддържа веднага стои въпросът:

А трябва ли ти? А на кой от потребителите и в какви случаи му трябва?

Този въпрос стои винаги - за всеки един софтуер и всъщност е определящ.

Пример от Windows. Използвам Notepad - ама не можел да сменя шрифтове и не разбирал от форматиране и не поддържал....
Е да де ама аз го използвам за да си редактирам autoexec.bat примерно. Или пък да си разпечатам бележка на която пише "Водомера ми показва 99999" и да я лепна на вратата за инкасатора.

С какво ще ми помогнат шрифтовете? Трябва ли да дам още XXX $ за да си купя MS Office само за да си свърша ТОЧНО ТАЗИ работа?

Хайде обратно. Правиш уеб сайт за някакво Списание. Списанието се обновява веднъж седмично и толкоз. Е за какво са ти транзакции? Ама нямало :) Ами трябват ли?



За XML-а - и четеното на документацията:
Току-що ми помогна да открия един пропуск - заминава към Doc отбора. Благодаря всъщност

mysql.online.bg/doc/en/mysql.html т.е. глава 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....

salle.online.bg/sig

Ami tova beshe malko otklonenie ot temata (zashtoto osporih s izkazanoto mnenie che XML niama nishto obshto s bazite danni). A inache mnenieto mi za standartite e [линк]
i v obshti linii se svejda do tova che daje da ima takiva standarti kakto SQL-a sega (samo entry level-a e na praktika standarten), pak e na dobre.

НЕ МЕ ЕБЕ КАК Е ВУТЕ, АЗ ГЛЕДАМ ДА СЪМ ДОБРЕ

> ОБАЧЕ. За огромно мое съжаление 90% от критиките спрямо MySQL по повод на
> Подзаявките са от рода на:
> Ми тази заявка не работи - начи MySQL е боклук.
> Тази заявка се оказва:
> SELECT a, b FROM x WHERE c IN (SELECT c FROM x WHERE d = 10);

Pravilniat vapros vinagi e bil - dali MySQL e podhodiashta za edi-koia si zadacha? kakvo shte mi dade smianata na MySQL s Oracle (primerno) i dali opravdava investiciata? Ima sluchai v koito naistina ima polza ot Oracle (kluster ot 32-procesorni mashini bicheshti Oracle za SAP) i v koito niama (website na spisanie koito se obnoviava 1 pat mesechno kato izkluchim forumcheto).

НЕ МЕ ЕБЕ КАК Е ВУТЕ, АЗ ГЛЕДАМ ДА СЪМ ДОБРЕ

форумите на дира на MySql ли са ?

очевадно

[линк]