Синтаксис MySQL vs. Синтаксис MSSQL.

[GSerg]

[Хакер] :: Отделено отсюда.

предварительно переведя его к дурацкому синтаксису MSSQL

Дурацкий синтаксис MS SQL соответствует стандарту ANSI SQL, в то время как идиотский синтаксис MySQL ему не соответствует.

[Хакер]

Писал и думал, заденет ли GSerg-а эта фраза (ведь обсуждали мы как-то эту тему в асе). Задела.

Однако не это важно. Мне, например, жутко режет глаза изобилие квадратных скобок, в которые надо заключать всё подряд: и название полей, и имена таблица, и даже (блин) тип поля надо заключать в скобки. И то что PRIMARY KEY при создании таблицы нельзя определить сразу - это тоже неоспоримое преимущество, да?

[alibek]

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

[Хакер]

Да, alibek, и в MySQL нужно, и именно обратные апострофы. И в этом отношении обратные апострофы не так бросаются в глаза и пестрят запрос, как это делают квадратные скобки.

[alibek]

Обратные апостофы отвратительны.
И как символ, визуально их представляющий, и как идея, что некая сущность помечается не парным символом (открывающий/закрывающий), а одним.

Что же касается бросания в глаза -- нет, мне квадратные скобки не пестрят.

[Хакер]

Пожалуй, тут я с тобой не соглашусь.

И как символ, визуально их представляющий

Не понял.

и как идея, что некая сущность помечается не парным символом (открывающий/закрывающий), а одним.

Парный маркер, помечающий некоторую конструкцию, там , где не может быть вложенных конструкций, совершенно, ну совершенно не нужен. (Докажи обратное, если сможешь)

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

Что же касается бросания в глаза -- нет, мне квадратные скобки не пестрят.

Ну, это уже вопрос вкуса. Тем более, если взять во внимание то, что и ты, alibek, и GSerg, и многие другие ежедневно используют MSSQL и уже "привыкли" к нему, они будут его защищать, а не MySQL, который юзали гораздо меньше или вообще никогда не юзали.

[tyomitch]

Обратные апостофы отвратительны.
И как символ, визуально их представляющий...

Плюсадын.
Обратная кавычка, вертикальная черта, и подчёркивание -- три ASCII-символа, забаненных из типографики.

(хоть это и не имеет ни малейшего отношения к их применимости в SQL)

[alibek]

и многие другие ежедневно используют MSSQL и уже "привыкли" к нему

А я вообще-то использовал самые разные базы. Если бы дело было в привычке, то я бы предпочитал двойные кавычки (как в Oracle), а не квадратные скобки.

[tyomitch]

емнип, в InterBase тоже двойные кавычки...

[alibek]

Парный маркер, помечающий некоторую конструкцию, там , где не может быть вложенных конструкций, совершенно, ну совершенно не нужен. (Докажи обратное, если сможешь)

К чему доказывать очевидное?
Более строгая и формальная структура разбирается гораздо легче, и парсером, и человеком.
В XML не поскупились на формализм и некоторую избыточность описания структур, зато его теперь обрабатывать легко.

[Хакер]

К чему доказывать очевидное?
Более строгая и формальная структура разбирается гораздо легче, и парсером, и человеком.
В XML не поскупились на формализм и некоторую избыточность описания структур, зато его теперь обрабатывать легко.

Глупость. XML предполагает описывание деревьев. Дереврьев, в которых узлы могут находится в других узлах, и в которых могут находиться другие узлы.

В таких случаях смысл делать парные маркеры есть.

В названии поля может быть название другого поля? А в нём ещё одно? А в утке яйцо? А в яйце игла?

- Нет.

Вылавливать строки их запроса со скобками и с апострофами одинакого.

Например, если делать это регекспом, то регексп будет `([^`]+)` в случае с апострофами, и \[([^\[\]]+)\] со скобками. Никакой практически разницы.

Кстати, о XML. Лично я не вижу никакого смысла в повторении тегов.
Какой смысл писать

Код: Выделить всё

<a>
     <b>
     </b>
     <c>
     </c>
</a>

когда достаточно

Код: Выделить всё

a
{
   b
   {
   }
   c
   {
   }

}

?

Во втором случае нам придётся делать стек. При встрече каждой открывающей скобки push-ить туда название блока, при встрече закрывающей, pop-ить, чтобы узанть, какой блок закрыли.

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

Однако существует пробелма перекрёстных тегов. И нам всё равно придётся проверять правильность структуры XML, и точно также пушить в стек имя тега, при встрече каждого открывающего тега, а при встрече каждого закрывающего - pop-ить, и сверять, совпадает ли то что указано между </ и > с тем, что лежало в стеке. И если вдруг не совпадает - орать, что XML порврёждён.

Выходит, стек придётся юзать в любом случае. В тём же тогда выгод? А пока вижу только проигрышь - избыточность - лишние данные в закрывающих тегах.

GSerg говорил в прошлый раз, что при использовании {}-скобок нельзя определить место ошибки (место, в котором пропущена открывающая или закрывающая скобка).

Однако во-первых, при использовании XML тоже не удастся определить однозначное местоположение ошибки, а во-вторых - если данные повреждены - в любом случае программа должна прекратить работать, а не пытаться загрузить уцелевшие данные.

[Antonariy]

Какой смысл писать

Код: Выделить всё

<a>
     <b>
     </b>
     <c>
     </c>
</a>

когда достаточно

Код: Выделить всё

a
{
   b
   {
   }
   c
   {
   }

}

?

И забыть про атрибуты? <a b="c">d</a> твоим способом не запишешь.

[tyomitch]

Antonariy, ты как будто бы C# не видел

Код: Выделить всё

[b(c)] a
{
   d
   {
   }
}


[keks-n]

чем-то напоминает idl...

[VVitafresh]

Поддержу холивар (и подразню Хакера -- пока только он один защищает MySQL).

Лично мне синтаксис Transact-SQL нравится многократно больше, чем тот, который в MySQL. Но в моем случае -- это привычка, т.к. с MySQL я работаю крайне редко, оттого его синтаксис мне режет глаза.

[Antonariy]

Antonariy, ты как будто бы C# не видел

Код: Выделить всё

[b(c)] a
{
   d
   {
   }
}


Видел. Но не более того
И ни за что бы не догадался, что эта запись эквивалентна моей xml-ной.

[tyomitch]

Мало того, что в C# (и даже в idl) фигня в квадратных скобках тоже назвается "атрибуты", так она ещё и применяется к блоку, перед которым стоит. Так что всё по-честному.

[Хакер]

И забыть про атрибуты? <a b="c">d</a> твоим способом не запишешь.

Запишу. Или тем способом, который предложил tyomitch. Или своим способом, для которого у меня даже есть написанный парсер.

Атрибуты будут выглядекть так:

Код: Выделить всё

a(b="c";e="asdasd")
{
      d
      {
      }
}

Однако "мой синтаксис" позволяет в делать комплексный аргумент. А именно:

Код: Выделить всё

a(b="c";e=foo(e1="a";e2="b";e3="c"))
{
      d
      {
      }
}


или даже:

Код: Выделить всё

a(b="c";e=foo(e1="a";e2="b";e3="c") { ...что-нибудь... })
{
      d
      {
      }
}


Слабо сделать такое в XML ?

[alibek]

Однако "мой синтаксис" позволяет в делать комплексный аргумент. А именно:

Приведи хотя бы один пример из практики, когда это может пригодится и при этом вложенные узлы из XML не подойдут.

[alibek]

или даже:

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

[Хакер]

Приведи хотя бы один пример из практики, когда это может пригодится и при этом вложенные узлы из XML не подойдут.

Нужно сериализовать сведения об отделах. У каждого отдела есть "руководитель" класса person. Отдел - пусть будет union, атрибуты: название "name", руководитель отдела "maintainer", ну и достаточно. Основаная цель: передать список разработок отдела (класс "product"). У каждой разработки есть имя "name", стоитмость "cost", заказчик "customer" (класса "person"), ведущий программист "maintainer" (класса "person") и пожалуй хватит. У каждой разработки может быть ещё-что то, но мне лень придумывать - описаного выше достаточно.

Мой код:

Код: Выделить всё

union(name="Отдел 1";maintainer=person(name="Иван Васильевич Бунша";age=47;gender=1))
{
    product(name="Программа 1";cost=4862;customer=person(name="Вася Пупкин";age=20;gender=1);maintainer=person(name="Павлик Морозов";age=25;gender=1))
    {
        ...что-нибудь...
    }
   
    product(name="Web-сайт ЦУуцуц";cost=9842;customer=person(name="Йцукен Вапр";age=7;gender=0);maintainer=person(name="Ирина Колобкова";age=30;gender=2))
    {
        .. ещё-что нибудь ...
    }
}

union(name="Отдел 2";maintainer=person(name="Наталья Иванова";age=35;gender=2))
{
    product(name="Комплекс Альфа";cost=100;customer=person(name="Шубин Андрей";age=60;gender=1);maintainer=person(name="Зуров Василий";age=18;gender=1))
    {
        ...что-нибудь...
    }

    product(name="Комплекс Бета";cost=1000;customer=person(name="Иванов Иван";age=27;gender=1);maintainer=person(name="Мария Власова";age=24;gender=2))
    {
        .. ещё-что нибудь ...
    }
}


А как это будет выглядеть в XML-представлении? Так что-ли: ?

Код: Выделить всё

<union name="Отдел 1">
    <maintainer>
        <person name="Иван Васильевич Бунша" age=47 gender=1 />
    </maintainer>
    <products>
        <product name="Програма 1" cost=4862>
            <customer>
                <person name="Вася пупкин" age=47 gender=1 />
            </customer>
            <maintainer>
                <person name="Павлик Морозов" age=25 gender=1 />
            </maintainer>
            <content>
               .... что-нибудь ....
            </content>
        </product>
        <product name="Web-сайт ЦУуцуц" cost=9842>
            <customer>
                <person name="цукен Вапр" age=7 gender=0 />
            </customer>
            <maintainer>
                <person name="Ирина Колобкова" age=30 gender=2 />
            </maintainer>
            <content>
                ... ещё что-нибудь ...
            </content>
        </product>
    </products>
</union>
<union name="Отдел 2">
    <maintainer>
        <person name="Наталья Иванова" age=35 gender=2 />
    </maintainer>
    <products>
        <product name="Комплекс Альфа" cost=100>
            <customer>
                <person name="Шубин Андрей" age=60 gender=1 />
            </customer>
            <maintainer>
                <person name="Зуров Василий" age=18 gender=1 />
            </maintainer>
            <content>
               .... что-нибудь ....
            </content>
        </product>
        <product name="Комплекс Бета" cost=1000>
            <customer>
                <person name="Иванов Иван" age=27 gender=1 />
            </customer>
            <maintainer>
                <person name="Мария Власова" age=24 gender=2 />
            </maintainer>
            <content>
                ... ещё что-нибудь ...
            </content>
        </product>
    </products>
</union>

Я думаю, разница очевидна


____________________________________________________

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

Вот как-раз-таки я сравнил два примера, который я привёл в качестве ответа на твой первый вопрос.

[Antonariy]

Разница очевидна, а где же выводы?

Какое отношение количество текста имеет к сложности структуры? Генерация и обработка обычно возлагаются на программные средства, а не топтателей клавиатуры. В XML структура проще, значит обрабатывается быстрее. И не важно, что объем больше. Или я не правильно интерпретировал смысл примера?

[keks-n]

Хакер
Я пока что вижу нечитабельность твоего варианта.

[Хакер]

Да чем она проще то? Тем ли, что в закрывающем теге написано, что именно закрываем? Или чем то ещё? Я не вижу больше никакой разницы между XML и моим синтаксисом, кроме как использования } вместо </somthing> и разделения пргументов ; а не пробелом.

Возможность присваивать аргументу объект мы отбросим, потому как XML не поддерживает это. Это просто бонус моего протокола.

Поставим XML и мой способ в раные условия. Различны только две вещи - способ завершения блока и разделение аргументов.

Из-за этих двух вещей XML вдруг стал проще? Не поверю что из-за них его быстрее разбирают парсеры.

А теперь возьмём другую сторону: объём данных. Тот же RSS-Feed, при использовании моего протокола стал бы куда меньше в объёме. А значит быстрее бы шёл по сети + намотал бы меньше трафика.

Я, кстати, отмечу, что я этот протокол (и парсер) разрабатывал исключительно для одной программы, которая должна была получать от сервера много структурированных данных. Правда всё обломалось, из-за превышения сроков разрабокт. Наверное, в этом преимущество XML... в том что не нужно тратить время на написание своего парсера, а юзать готовый MSXML.

Но если бы MS написал свой парсер для {}-синтаксиса...

[Antonariy]

Да чем она проще то?

Меньше правил парсинга.

Возможность присваивать аргументу объект мы отбросим, потому как XML не поддерживает это. Это просто бонус моего протокола.

Поставим XML и мой способ в раные условия. Различны только две вещи - способ завершения блока и разделение аргументов.

Ну уж нет, ничего отбрасывать не будем. В xml можно же записать твои комплексные аргументы отдельной нодой, вот и запишем. И это будут истинно равные условия. Если твой пасер работоспособен, то нужно просто сравнить скорость разбора твоего документа со скоростью разбора аналогичного xml.

А теперь возьмём другую сторону: объём данных. Тот же RSS-Feed, при использовании моего протокола стал бы куда меньше в объёме. А значит быстрее бы шёл по сети + намотал бы меньше трафика.

А если кодировать данные байтами да еще ужать каким-нибудь раром, то будет еще меньше. Вот только xml разрабатывался не для экономии на спичках.

[Хакер]

Ну уж нет, ничего отбрасывать не будем. В xml же можно записать твои комплексные аргументы отдельной нодой. Это будут истинно равные условия. Если твой пасер работоспособен, то нужно просто сравнить скорость разбора твоего документа со скоростью разбора аналогичного xml.

Требую пример в подтверждение выделенных слов.

[tyomitch]

Если твой пасер работоспособен, то нужно просто сравнить скорость разбора твоего документа со скоростью разбора аналогичного xml.

На самом деле, это решающий аргумент. Предлагаю его не заминать.

Что касается сжатия данных при передаче поверх Интернета, то это забота более нижележащих протоколов, чем XML (например, HTTP позволяет прозрачно гнать любой документ по сети сжатым).

[Antonariy]

Хакер, я пацтулом.

Код: Выделить всё

<product name="Програма 1" cost=4862>
            <customer>
                <person name="Вася пупкин" age=47 gender=1 />
            </customer>
            <maintainer>
                <person name="Павлик Морозов" age=25 gender=1 />
            </maintainer>
            <content>
               .... что-нибудь ....
            </content>
</product>

Это чей пример?

[Хакер]

Antonariy
Это лишь жалкий обход недоразвитости XML. Здесь customer и maintainer ноды, а не аргументы. А в моём случае - аргументы.

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

Но пример принимается.

Кто будет писать XML-парсер?

[tyomitch]

Как кто, Microsoft
Речь ведь шла о сериализации объектов?
Вон, .нецкие объекты отлично умеют сериализоваться в XML.