Ответ
Misha v.3 14.01.2008 23:10
разделю свой ответ на 3 части: первая по сути вопроса, вторая -- по поводу экранирования имён таблиц в запросах и третья -- теоретическая демагогия, которую многоуважаемый egr так любит.
1. вообще-то речь шла про имена столбцов. с тем, что их имена при отдаче клиенту сервер как-то модифицирует я встречался только у оракла старой версии (8.0x, как у новой -- не знаю, возможно и у старой это задаётся настройками). ни один другой сервер ничего подобного в моей практике никогда не делал. причем модифицирование касалось только изменение регистра возвращаемого имени. с проблемами из-за совпадения
имени столбца с зарезервированым словом я никогда не встречался. заключать названия столбцов в escape-символы конечно можно, но на практике-то это зачем?
2. утверждать что кто-то не разобрался, не имея на то веских оснований -- в моём мировозрении не есть хорошо.
если говорить о том, что по хорошему имена таблиц в запросах надо заключать в спец символы, то лично я в этом разобрался ещё году в 2002. более того, я попробовал два варианта обхода этого неудобства (1. название таблиц auser и asession появилось не просто так; 2. в одном из классов использую таблицу resource, которая при составлении запросов обрамляется символами '"' в случае oracle и символами '`' в случае mysql (или '"' в случае mysql strict). да, вариант с объектной моделью я не использовал, но об этом -- в пункте 3). через некоторое время я почти полностью отказался от реализации с использованием escape-символа в пользу выбора не запрещенного имени таблицы. причина проста -- escape-символы добавляют кучу дополнительной головной боли (кода) без каких-либо плюсов.
однако замечу: у меня никогда не стояла задача в создании приложения, работающего с любым SQL сервером или с определённым набором SQL серверов. задача всегда ставилась иначе: написать код, который
при необходимости несложно перенести на другой SQL сервер. причина этого понятна: подавляющее большинство наших заказчиков не имели собственных SQL серверов (а если имели, то частенько не имели администраторов), а наш выбор -- mysql, в том числе по причине высокой скорости на выборках (мы же помним, что пока говорим про веб приложения, которые в большинстве своём достаточно просты с точки зрения БД и работают в основном на выборку данных, но это я отвлёкся).
создать приложение, эффективно работающее на абсолютно произвольном sql сервере считаю почти неразрешимой задачей, т.к. в конечном счёте найдётся сервер, который не знает чего-либо, и придётся достаточно кардинально менять приложение, т.к. существующей абстракции в созданной абстрактной модели будет недостаточно. поэтому правильнее говорить о написании приложения для перечисленного списка серверов (с номерами версий, MySQL 3 совсем не то-же самое, что MySQL 5, а Oracle 8 -- не тоже самое что Oracle 10). для ограниченного списка серверов совсем не сложно заранее учесть список зарезервированных слов или обойти его, например простым добавлением префикса в имя таблицы или... и тут мы переходим к третьей части марлезонского балета...
3. теория это одно, практика -- совершенно другое. и они очень далеки друг от друга. если инженер для того, чтобы закрутить одну гайку предлагает сначала разработать и внедрить линию сборки -- я считаю что с этим инженером что-то не то. зазанее, из благородных целей разработать и создать предлагаемый абстрактный класс, а потом заниматься его поддержкой -- считаю пустой тратой времени. для простых случаев время его создания превысит время переписывания кода для адаптации к новым условиям.
да, я знаю что написаны кучи умных книг, в которых теоретически обосновывают кучу всего, и в подавляющем большинстве случаев они логичны, но... они не подходят для всех случаев жизни. да вообще нет теорий, идеальных для всех случаев жизни. никто не использует ОТО там, где хватает точности Ньютоновской механики. не считаю оправданным написание абстрактной объектной SQL модели в качестве прослойки для гостевой книги, где всего имеется 4 sql запроса.
я не утверждаю что теория -- отстой. нет, она -- ориентир, она -- идеал, который нужно знать (чтобы её части использовать в нужных местах) и к которому безусловно нужно стремиться. возвращаясь к программированию: я не уверен что существует большое количество реально работающего и используемого кода, который написан вообще без нарушений красивых теорий.
я думаю ты без труда сможешь найти вагон и маленькую тележку непоколебимых принципов, которые я нарушаю, в том числе своей этой демагогией. я же ориентируюсь в основном на один: принцип Окама ("не плоди сущностей без необходимости").
когда будешь искать список нарушенных теорий не забывай про изречение Леонардо да Винчи: "Кто спорит, ссылаясь на авторитет, тот применяет не свой ум, а скорее память".
P.S. дискутировать тут можно бесконечно. если хочешь -- продолжай, но я отвечать на это не буду.
