Я использую ms sql, и мне нужно создать таблицу со столбцом массива nvarchar. Какой правильный запрос?
Нет столбцов массива. В языке SQL поля должны содержать значения Один. Это может быть одно значение сложный, например координата, но это все же одно значение, которое обрабатывается как один элемент. Даже в базах данных с массивами, таких как Oracle, они обрабатываются как один элемент, и их содержимое не может быть спросил по отдельности. Что ты пытаешься сделать?
мне нужно создать таблицу, которая содержит так много столбцов, но 60 из них похожи, и я хочу вставить это в массив. Есть ограничение на столбец таблицы?
@PanagiotisKanavos: на самом деле стандарт SQL делает определяет массивы (и Oracle не имеет массивов в качестве типа данных в SQL, только в PL/SQL)
@a_horse_with_no_name Oracle позволяет хранить массивы, по крайней мере, начиная с Oracle 8i. Я использовал эти функции, когда работал с клиентом, которому нужны были пространственные функции без дополнительной оплаты. Забавный факт: в Oracle 8i была критическая ошибка, из-за которой вы не могли читать данные Любые после того, как превышали неопределенный размер данных. Конечно КБ и фикс отстали и НДА...
У меня есть таблица для сохранения даты автомобиля. Для каждой машины я хочу сохранить 60 аксессуаров и 50 опций. По этой причине я хочу сохранить это в два массива, но это невозможно. Какое лучшее решение для этого?
@AttilioIurlaro: вам нужны дополнительные таблицы для хранения отношений «один ко многим». Пожалуйста, прочитайте о нормализации базы данных
@AttilioIurlaro, это не так много столбцов. Вам нужно фильтровать по этим столбцам? Индексировать их? Тогда они должны быть отдельными столбцами, независимо от базы данных. Вы не будет экономите Любые пространство, используя массив .... чего? Каждый атрибут представляет собой данные типа разные.
@PanagiotisKanavos: вложенные таблицы Oracle отличаются от массивов (по крайней мере, с точки зрения стандарта SQL, но сейчас это совершенно не по теме)
Я второй @a_horse_with_no_name, сохраняю эти значения в отдельной таблице (N: 1) в исходной таблице. Вы можете легко агрегировать их как одно значение и одновременно использовать все функции поиска sql.
@PanagiotisKanavos тип данных тот же
@ AttilioIurlaro то же самое, что? Сомневаюсь, что у любого уголька есть 50 цветов или 50 пепельниц. Тип данных нет совпадает с типом поля. Точно так же, как вы не можете использовать аквамарин, чтобы зажечь сигарету или зарядить телефон, вы не можете хранить их в одном и том же поле. Если вы не собираетесь фильтровать по этим полям, а также всегда намереваетесь загружать их все, вы можете использовать одно или несколько полей JSON для хранения дополнительных данных в формате JSON. Даже в этом случае атрибуты должны быть описательными, например { 'color':'aquamarine', 'rear_ashtray':'yes'}
@AttilioIurlaro проблема, которую вы описываете, гораздо сложнее, чем 50 optional fields. Один вариант может иметь свои части и опции. Это спецификация, которую легче смоделировать в графической базе данных. В SQL Server иерархические структуры часто используются для моделирования части, состоящей из других частей.


Вам не нужен столбец массива. Вам нужна отдельная таблица (или, возможно, столбец JSON/XML, но я не буду заострять на этом внимание).
Обычный метод:
create table main (
main_id int identity primary key,
. . .
);
create table element (
element_id int identity primary key,
position int,
value varchar(255),
. . .
);
create table main_elements (
main_element_id int identity primary key,
main_id int references main(main_id),
element_id int references elements(element_id)
);
Невозможно. SQL Server не поддерживает массивы, но с самого начала это плохая идея. Почему вы должным образом не нормализуете свою модель данных?