Lift Два.Ноль

>Не обязательно. Это может быть чем угодно что ввел туда пользователь. НАпример «не забудь проставить сумму до 15».

в это уже не maybe, а обычный стринг или бинари блоб, если интересует только хранение.

Он может работать аналогично сортировке чисел с нулами.

да не будет оно работать. как можно отсортировать число 10 и «чуть более, чем десять»?

Эти данные - не мусор - их пишут туда осознано. Осознанно - знчит преследуюя некую цель.

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

А ценность БД накапливается годами и состоит в отчетах, которые должны разгребаться автоматом ибо объем в миллионы записей вручную не просмотреть и источник данных для других систем, например, рассылка оповещений, где тоже некошерно ставить вместо факса «а хуй его знает».

это нормальное требование даже для банального вебмагазина

Ага, поэтому товары в таких магазинах регулярно не попадают в таргет категорию и покупатель уходит в поисках на другие веб-магазины. Я регулярно отсылаю багрепорты менеджерам techhome.ru у которых какой-нибудь CorsairSSD невозможно увидеть, выбрав в жестких дисках категорию SSD, даже бренд Corsair при этом недоступен. Хотя SSDшки у них есть, просто кто-то «забыл» привязать их к SSD. А если покупатель точного названия не знает? он уходит не найдя товар

А зачем Corsair, если Vertex 2 интересней на порядок?

>Мы о проектах в которых лепят субд для хранения данных

все эти проблемы - горькое наследие RAD с БД, типа дельфи. Сначала эти быдло-куны лепят формочки с прямой связью контрол<->поле данных в БД. Затем возникает вопрос, «а как мне записать в поле телефона еще и ФИО для связи»? и пошел зубовный скрежет.

При этом в терминальной стадии эти вечные студенты требуют какой-нибудь быдляцкий дбгрид в гтк!

>в это уже не maybe, а обычный стринг или бинари блоб, если интересует только хранение.

Это в текущих реляционках. А можно хранить так чтобы было понятно.

да не будет оно работать. как можно отсортировать число 10 и «чуть более, чем десять»?

А как можно сортировать 10, -10 и NULL?

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

Не превращается.

А ценность БД накапливается годами и состоит в отчетах, которые должны разгребаться автоматом ибо объем в миллионы записей вручную не просмотреть и источник данных для других систем, например, рассылка оповещений, где тоже некошерно ставить вместо факса «а хуй его знает».

В задачах датамайнинга. К ним пожалуста Кодд. Только что-то мне подсказывает что задачи датамайнигда достаточно редкая вещь.

> Ага, поэтому товары в таких магазинах регулярно не попадают в таргет категорию и покупатель уходит в поисках на другие веб-магазины.

Потому что там внизу мускуль и тот кто это писал больше болел как это все туда поместить, а не решать именно вопросы создания софта

> никто не отменял и рекомендательной логики вида 'это поле таки лучше заполнить или в месячном отчете данная запись не будет учтена" вместо «а ну введи сюда число сука иначе я вообще нихрена не сохраню».

Отменять то её не отменяли, но человек - тварь ленивая, и клинические испытания показывают, что на такой «рекомендательной» логике далеко не уедешь. С десятком никому не нужных полей типа «любимый цвет» на сайте для дамочек-за-тридцать это прокатит, в финансовой системе - практически исключено.

>>А ценность БД накапливается годами и состоит в отчетах, которые должны разгребаться автоматом ибо объем в миллионы записей вручную не просмотреть и источник данных для других систем, например, рассылка оповещений, где тоже некошерно ставить вместо факса «а хуй его знает».

В задачах датамайнинга. К ним пожалуста Кодд. Только что-то мне подсказывает что задачи датамайнигда достаточно редкая вещь.

Если данные никем не будут обрабатываться, то и хранить их в общем-то по большому счету незачем.

К.О.

>в финансовой системе - практически исключено.

Я так понимаю большинство софта использующийх СУБД - это финансовые системы?

>Если данные никем не будут обрабатываться, то и хранить их в общем-то по большому счету незачем.

В большинстве случаев данные «обрабатываются» максимум для поиска а хранятся для истории.

Потому что там внизу мускуль

Так внизу не мускуль а мсскл, сайт на asp.net

А зачем Corsair, если Vertex 2 интересней на порядок?

Сейчас у меня Intel 80G, а когда выбирал, за 5000 был только Corsair

>Так внизу не мускуль а мсскл, сайт на asp.net

Без разницы.

> Я так понимаю большинство софта использующийх СУБД - это финансовые системы?

В принципе - да. Если считать не по инсталированным инстансам phpBB, а по используемым в работе и поддерживаемым софтинам, разумеется. Для научных расчетов часто используют другие хранилища. Кое-где, кстати, всё еще живут на dbf/foxpro и К.

Ну и быдловеб опять же прекрасно себя чувствует на реляционных БД. Если мы про корпоратив - то там народ лишней буквы не напечатает без надсмоторщика с хлыстом. Если мы про открытый ресурс - там админам и службе поддержки лишнаяя инфа нахрен не уперлась. Все твои ужасы про чукчей, которые что хотят, то и поют, и вообще не понимают нахрена им БД, выглядят уж через чур сферично в вакууме, и больше похожи на развод шефа/компании на нахрен ей не нужный софт, либо полную и безоговорочную непрофпригодность аналитика, чем на проблемы РМ.

> данные «обрабатываются» максимум для поиска а хранятся для истории.

Такое «большинство» вообще нет смысла рассматривать, так это use-case для лог-файла. Если бд используют как бэкэнд для лога - это не проблемы ни бд, ни РМ.

> В принципе - да.

В принципе настолько же насколько РС - самій распространенній тип компьютераю то есть ненасколько.

Ну и быдловеб опять же прекрасно себя чувствует на реляционных БД.

Ага - конечно. Тото я смотрю гугл на оракле работает.

Если мы про корпоратив - то там народ лишней буквы не напечатает без надсмоторщика с хлыстом.

И надсмотрщики хотят чтобы все было так как они хотят а не «пэхепэ программист требует».

. Все твои ужасы про чукчей, которые что хотят, то и поют, и вообще не понимают нахрена им БД, выглядят уж через чур сферично в вакууме,

Это реальность любого СааС и любых корпоративных систем поставляемых более чем в одном экзэмпляре. Она называется «клиенты все разные и каждый хочет как именно ему удобно».

либо полную и безоговорочную непрофпригодность аналитика,

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

>Такое «большинство» вообще нет смысла рассматривать, так это use-case для лог-файла.

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

>Это в текущих реляционках. А можно хранить так чтобы было понятно.

ога, пошли фантазии. Я не против, просто решение проблемы лежит совсем в другой плоскости.

А как можно сортировать 10, -10 и NULL?

первые два согласно правилам арифметики. Нуль не определен, но он один, так что он во всей базе будет в предсказуемом месте.

Не превращается.

плавали, знаем. Даже сам оператор уже через неделю не помнит, зачем он это написал.

В задачах датамайнинга. К ним пожалуста Кодд. Только что-то мне подсказывает что задачи датамайнигда достаточно редкая вещь.

они везде. просто кое-где считают возможным сливать собственное конкурентное преимущество.

>ога, пошли фантазии.

Чего это фантазии? Ты что - без рук? Или по твоему программисты делятся на бохов микрософта способных написать базу данных и остальных способных только ею пользоваться? Я лично последние 6ть лет использую только самописные специализированные хранилища.

Нуль не определен, но он один, так что он во всей базе будет в предсказуемом месте.

Все точно так же. Правила сортировки мєйбитипа + все остальное в конце - как самое простое решение.

Даже сам оператор уже через неделю не помнит, зачем он это написал.

Тем не менее есть в природе люди осознающие зачем они что-то делают, и желающие чтобы система этому не сопротивлялась.

они везде.

Это не так.

просто кое-где считают возможным сливать собственное конкурентное преимущество.

Вот именно - есть различные свойства и свойства эти имеют различный вес. Если у вац цель написать структурированную мегабазу в которой хранятся миллионы записей и писать к ней различные морды - и это первичная цель - значит «схема и sql» имеют существенный вес. Но если цель - хранение гетерогенных данных, или древовидных структур - реляционные базы идут лесом. Просто датамайнинг по ним делать надо будет другими инструментами.

Прости, но пришельцами из альтернативной реальности занимаются в соседнем кабинете.

>Прости, но пришельцами из альтернативной реальности занимаются в соседнем кабинете.

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

>Чего это фантазии? Ты что - без рук?

написание еще одной БД в мои планы пока не входит. Есть postgresql, mysql и sqlite.

Или по твоему программисты делятся на бохов микрософта способных написать базу данных и остальных способных только ею пользоваться? Я лично последние 6ть лет использую только самописные специализированные хранилища.

зачем? Множить баги?

Правила сортировки мєйбитипа + все остальное в конце - как самое простое решение.

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

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

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

Тем не менее есть в природе люди осознающие зачем они что-то делают, и желающие чтобы система этому не сопротивлялась.

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

>написание еще одной БД в мои планы пока не входит.

А тебя никто не просит писать еще одну бд. Ты что используешь 100% возможностей БД?

зачем? Множить баги?

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

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

Научная фантастика:

[code]
object MaybetypeTest {
   trait Value
   case class IntValue( val value: Int ) extends Value
   case class OtherValue( val value: String ) extends Value

   implicit object ValueOrdering extends Ordering[Value] {
      def compare( x: Value, y: Value ) = (x, y) match {
         case (IntValue( xv ), IntValue( yv )) => xv.compare( yv )
         case (OtherValue( _ ), _) => 1
         case (_, OtherValue( _ )) => -1
      }
   }

   def main( args: Array[String] ) {
      var list = IntValue( 4 ) :: IntValue( 1 ) :: OtherValue( «aaaaaa» ) :: IntValue( 5 ) :: OtherValue( «xxxxxx» ) :: Nil
      println( list.sorted( ValueOrdering ) )
      list = list ::: ( IntValue( 10 ) :: OtherValue( «bbbb» ) :: Nil )
      println( list.sorted( ValueOrdering ) )
      list = ( IntValue( 16 ) :: OtherValue( «yyyyy» ) :: Nil ) ::: list
      println( list.sorted( ValueOrdering ) )
   }
}
[/code]

[code]
List(IntValue(1), IntValue(4), IntValue(5), OtherValue(xxxxxx), OtherValue(aaaaaa))
List(IntValue(1), IntValue(4), IntValue(5), IntValue(10), OtherValue(bbbb), OtherValue(xxxxxx), OtherValue(aaaaaa))
List(IntValue(1), IntValue(4), IntValue(5), IntValue(10), IntValue(16), OtherValue(bbbb), OtherValue(xxxxxx), OtherValue(aaaaaa), OtherValue(yyyyy))
[/code]

нет таких.

Ты со всеми знаком?