Почему Oracle varchar2 имеет обязательный размер как параметр определения?

Несмотря на то, что на диске не выделяется заданное количество байтов, как в случае с полем char, все же есть веские причины для изменения размера:

• Память распределение на считывателях данных (на основе максимального размера строки)
• Индексирование большого столбца влияет на размер блоков
• И т. д.

Я уверен, что есть и другие причины, о которых может подумать кто-то еще, но те, которые я видел в прошлом проекте, где кто-то выбрал varchar2 (4000) все.

Просто интересно, если мы используем вышеупомянутую технику, как мы можем определить, на какой предмет была нажата кнопка?

Чтобы ответить на вопрос Брайана, в обработчике нажатия кнопки вы можете перейти к визуальному дереву, чтобы найти предмет, который содержит кнопку:

        DependencyObject dep = (DependencyObject)e.OriginalSource;
        while ((dep != null) && !(dep is ListBoxItem))
        {
            dep = VisualTreeHelper.GetParent(dep);
        }

        if (dep != null)
        {
            // TODO: do stuff with the item here.
        }

Вы ищете

voters.TakeWhile(p => {
   bool exceeded = voicesSoFar > voicesNeeded ;
   voicesSoFar += p.Voices;
   return !exceeded;
});

Если вы настаиваете на одном лайнере, это будет работать путем сравнения предыдущего значения:

voters.TakeWhile(p => (voicesSoFar += p.Voices) - p.Voices < voicesNeeded);

С точки зрения извлечения информации очень полезно знать, насколько велико поле. Например, если необходимо напечатать адрес на конверте или отобразить его на экране, необходимо знать, насколько большим должно быть поле.

Или купить ОЧЕНЬ большие конверты.

Я думаю, что важно помнить исторический контекст, в котором были разработаны реляционные базы данных. В то время, когда они разрабатывались (конец 70-х - начало 80-х годов) общедоступные компьютеры были намного меньше (в плане памяти и дискового пространства) и менее мощными (в плане процессора), чем сейчас, и управление этими ресурсами было неизбежной проблемой. COBOL был обычным языком бизнес-вычислений (и до сих пор широко используется), а объектно-ориентированные языки, такие как Smalltalk и C++, были неизвестны, для всех практических целей. В то время ожидалось, что программы будут точно объявлять, сколько памяти им потребуется для каждого элемента данных, например, 10 байт для строки, 2 байта для короткого целого числа, 4 байта для числа с плавающей запятой и т.д., и поэтому такой стиль объявления использовался только что разработанными реляционными базами данных. Более того, было сделано предположение, что каждый элемент данных будет объявлять (неявно или явно) объем памяти, который ему требуется, и это было заложено в реляционные движки на очень фундаментальном уровне.

Сейчас, со временем, это требование несколько смягчилось, по крайней мере, в том, что касается хранения данных на диске. Я полагаю, что в Oracle тип данных NUMBER будет гибко распределять пространство так, что будет использоваться только минимальный объем пространства, необходимый для хранения его значения, и что столбцы VARCHAR2 будут использовать достаточно места на диске для хранения фактических данных, не сохраняя пробелы, хотя вам все еще нужно объявлять максимальный объем памяти, требуемый для VARCHAR2.

Вы можете взглянуть на пакет SYS.STANDARD, чтобы получить представление о том, как объявлять подтипы VARCHAR2. Например, если вам нужен собственный тип 'string', который можно использовать без спецификации длины, вы можете попробовать:

SUBTYPE MY_STRING IS VARCHAR2(4000);

Однако, будьте осторожны с этим, если вы собираетесь индексировать рассматриваемый столбец (как указал @APC).

Я согласен, что лучше было бы просто объявить STRING (который, кстати, определен в SYS.STANDARD как подтип VARCHAR2) без необходимости объявлять длину, но Oracle работает не так, и поскольку я не собираюсь начинать писать свою собственную реляционную базу данных (у меня есть свои ветряные мельницы, на которые я могу накрениться, спасибо :-), я просто соглашусь со статус-кво.

Надеюсь, это поможет.

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

Но серьезно:

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