Я так понимаю, следующая стадия это считать, что 0 в числах маразматичен и порочнен, достаточно null  
А еще varchar2 в два раза лучше чем varchar  

"не любят" - неправильное выражение, скорее не берут в расчет при выборе платформы для разработки приложений, даже под "уиндоус"

Это сообщение отредактировал(а) Lazin - 22.3.2012, 11:08

LSD, вот реально, на практике сколько раз тебе доводилось выполнять операцию со строками подобную той, что ты продемонстрировал?
Я вот не припомню.
На том, что length от пустой строки возвращает null я не припомню, чтобы спотыкался даже в начале своего знакомства с оркалом. Обычно длина строки нужна для того чтобы определить больше ли она нуля или же меньше ли ее некое значение.

От того, что пустая строка эквивалентна null дискомфорт испытал лишь единожды, в самом начале своего знакомства c ораклом, пытался что-то заовнокодить, опираясь на различие пустой строки и null, досадовал что не получается.

Зато очень хорошо помню что при написании клиентов для других систем приходилось вешать чеки length(str)> 0 вместо обычных not null, т.к. при сохранении формы в базе не заполненные edit box'ы сохранялись как ''. Тоже и при разборе XML "<a/>" текст для этого элемента не определен, но экстракт по "/a/text()"  вернет пустую строку, сохраняем в базе - обманываем not null констрейнты.


Варчар круче. Но он пока сферический и в вакууме.

>>

А часто ли тебе в базе приходится парсить тексты, регулярки и т.п.?  




В этом весь Оракл. Куча древнего гoвна мамонта, оставшегося с 1979 года. Но за который они крепко держаться, и всех пытаются убедить, что это фича а не баг. Вместо того чтобы придти и сказать, с версия 12 будет обратно несовместима и мы вычистим оттуда весь шлак. Кому влом переписывать сидите на 11.

Вообще достаточно часто. Задача "вдувать по расписанию в базу CSV/XML c ftp" уже набила жуткую оскомину.
Но я не понял к чему этот вопрос.


Вообще есть мнение, что varchar это не депрекейт вовсе, а резерв фо фьючер юз. А varchar2 называется так чтобы не путали с ансишным вачрчаром, т.к. его поведение, в части сравнения с null отличается от описанного в стандартах. 

Если ты архаичным гуано называешь именно тип varchar2... К той же категории можно отнести и все строки фискированной длинны, которые в новых проектах никем не используются, но поддерживаются практически всеми движками баз данных. А за счет того, что эти типы данных были опрометчиво стандартизированы, их поддержку придется обеспечивать и в новых, не скучных СУБД, буде такие появятся. Зачем допиливать ансишное поведение ораклиным строкам - вопрос весьма не однозначный. Я, например, не могу на него сходу ответить. Шаблоны это рвет только тем кто не привык к этому. Тем же кто привык, это практически не доставляет неудобства, зато профит - очевиден. Я, лично, не уверен что прейду на varchar, если оракл его реализует, и его отличие от varchar2 будет лишь в части синонимичности пустоты и неопределенности. Мне такой varchar будет определенно менее удобен.

Если ты архаичным гуано зазываешь прочие плюшки от оракла... вроде версионной изоляции транзакций, реализованной в пику имеющихся тогда(да и сейчас) стандартам, не в полной мере их поддерживающих... То, на сколько мне известно, этот тип изоляции уже вройкак пытаются стандартизировать как обособленный, майкрософт его уже с 2005й версии и к себе допилил в какой -то степени. Уж больно офигительно это получилось в конце то концов.

http://www.teobit.ru/
и здесь есть несколько сайтов: http://www.teobit.ru/#Portfolio
сайты написан на Morfik`e

Ты их парсишь руками (substring/regex)?
Просто когда шаблон совпадает с пустой строкой, получить null вместо этой самой строки довольно неприятно.




Я называю древним гoвном мамонта, несовместимости со стандартом и явные косяки:
- пустые строки
- null и уникальные индексы
- varchar2




Ты называешь преимуществами те фишки которыми пользуешься сам в своем проекте (как длинные транзакции), а те что не используемые относишь к "никому не используемым"  
Я вот длинные транзакции использовал всего один раз, да и они бы прекрасно сработали и на любой другой базе. А строки фиксированной длинны использовать приходилось чаще, как правило это некий идентификатор фиксированного формата.

CSV - да.
Для разбора XML есть нативные инструменты.


Тут я опять не уверен, что понимаю что ты имеешь в виду. Но если бы я наталкивался на эту неприятность, я, наверное, запомнил бы, и, вероятно, понял бы о чем ты ))

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


Это офигенно же! Часто доводится этой фичей пользоваться. Без нее, прям даже не представляю - как без рук. 

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


Я не вижу особых преимуществ хранения идентификаторов фиксированного формата в строках фиксированной длинны. Быть может даст экономию каких то спичек на перфомансе. Сам храню такие в варчар2.


Этот пункт повторяет первый. Наверно для большей весомости повторен  


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

Добавлено через 10 минут и 57 секунд

Зато вот, кстати, вспомнилось. Сейчас имею неприятности на интеграции с PG. PG сохраняет пустые строки в not null поля. Эти пустые строки, не будучи не определенными, упаковываются в пустые элементы xml, размеченные в DTD как обязательные и, соответственно успешно валидируется. Блин, неужели это противоречит "человеческой" логике, что если, скажем, поле "номер  документа" или "ГТД" размечены в как обязательные для заполенния, то пустой строки там быть не должно.  

Топик не читал. Выскажу свою версию по сабжу.
Во-первых, Delphi не так уж сильно не любят. Многим просто параллельно. Большинство нелюбящих его тупо не видели никогда, и ругают по принципу "все побежали, и я побежал". Остальные, видимо, никак не могут смириться с тем, что хоронят его уже второй десяток лет, а он, с**ко, никак не умирает    А сейчас, говорят, у Embarcadero продажи растут на 50% в год, так что новая анти-delphi волна не загорами, запасайтесь попкорном.   

Я наоборот замечал что ругают как раз те, кто с него ушли. А тем кто не видели его, тем он по-барабану.


А по мне так он давно мёртв. То, что его продают, ещё ничего не доказывает.

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

А как же шарп и дядя Билли?   

Ну например вычислить сколько пробелов надо для padding-а:

и вместо ожидаемого col_width получаем null. Очень мило  




Обратно, нет никаких причин отказываться от них.




Наверно для того чтобы напомнить, что даже в такой простой вещи как типы данных Оракл умудрился выпендриться и сделать полностью несовместимую вещь. Простейщий create table не перенесешь на другую СУБД, без ручной правки.

Тип DATE тоже не соответствует стандарту, но что-то они не спешат вводить DATE2  




Ты явно не понимаешь проблему, но пытаешься переложить ее на PG. У тебя проблема с валидацией входных данных, поля "номер  документа" или "ГТД" не могут быть не только пустыми строками, но и строками состоящими только из пробелов, не может там быть и иероглифов и т.д. Оракл выполнял за тебя одну простейшую проверку и ты почему-то решил, что это круто и этого достаточно.

http://www.spring4d.org/

А как бы ты падил на другой, более православной, субэдэ? Где исходная строка может принимать как не определенное значение, так и значение пустой строки? Если у тебя поле nullable, тебе всяко пришлось бы на это закладываться. Если нет, то - нет.


Да, я действительно не понимаю принципиального различия между пустой строкой и не определенным значением. Я действительно не могу придумать что может характеризовать пустая строка иначе как неопределенность. 


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



Да, было бы классно. Меня задолбало всякий раз придумывать имя для атрибута даты сущности, не пересекающееся с зарезервированными словами. Зачастую приходится его префиксовать именем сущности. Масло же масленное выходит... ASN.ASN_DATE  . DATE2, определенно, решило бы эту проблему   


Это сообщение отредактировал(а) Zloxa - 29.3.2012, 13:46