Для этого вам не нужны тысячи столбцов. Это стандартный один-ко-многим между тремя таблицами: questionaire
, question
и answer
:
create table questionaire
(
id integer not null primary key,
customer_name varchar(100) not null
);
create table question
(
id integer not null primary key,
questionaire_id integer not null references questionaire,
question_text varchar(20000),
sort_order integer
);
create table answer
(
question_id integer not null references question,
answer_text varchar(20000),
user_name varchar(50) not null,
primary key (question_id, user_name)
);
В действительности вы не на самом деле хранить имя пользователей компьютера находится в answer
таблице. Если вы назвали пользователей, которые вошли в систему, вам, вероятно, также понадобится таблица user_account
, а таблица question
будет ссылаться на таблицу user_account
.
Вы можете легко запросить эту модель без необходимости перехода к ключу/магазину значения или JSON
Чтобы получить все questionaires от клиента
select *
from questionaire qu
where customer_name = 'Some company';
Получить все questionaires и количество вопросов в клиент
select qu.customer_name,
count(distinct qu.id) as num_questionaires,
count(q.id) as total_questions
from questionaire qu
join question q on qu.id = q.questionaire_id
group by qu.customer_name;
Получить все ответы на анкете от конкретного пользователя
select q.question_text, a.answer_text
from answer a
join question q on q.id = a.question_id
join questionaire qu on qu.id = q.questionaire_id
where qu.id = 1
and a.user_name = 'Marvin'
order by q.sort_order;
немного сложнее, но, вероятно, все еще достаточно быстро, даже с тысячами вопросов и ответов: найти пользователей, которые не ответили на все вопросы
select aq.user_name, aq.questionaire_id, aq.answered_questions, tq.num_questions
from (
select a.user_name, q.questionaire_id, count(*) as answered_questions
from answer a
join question q on q.id = a.question_id
group by a.user_name, q.questionaire_id
) aq join (
select questionaire_id, count(*) as num_questions
from question
group by questionaire_id
) tq on tq.questionaire_id = aq.questionaire_id
where aq.answered_questions < tq.num_questions;
SQLFiddle пример: http://sqlfiddle.com/#!15/0a4e5/1
Вы также не должны пытаться перенести строки для каждого вопроса (или ответа) в столбец SQL - вы будет в конечном итоге ударить некоторые ограничения количества столбцов, которые может управлять. Реляционные базы данных были разработаны для обработки строк, много строк, а не «тысяч столбцов». Транспонирование строк в столбцы обычно выполняется на уровне представления вашего приложения (или, например, с использованием функции Pivot в электронной таблице)
Таблица с 1000 столбцами обычно является признаком плохой конструкции базы данных. Можете ли вы объяснить нам, почему вы думаете, что вам нужно столько столбцов? И почему вы не можете просто создать их с помощью команды 'create table'? –
Что касается вопроса: «* но почему HSQLDB не поддерживает его». Ответ на удивление просто: потому что никто еще не реализовал его. Это проект с открытым исходным кодом, поэтому, если вам это действительно нужно, вы можете добавить эту функцию. –
Слышали ли вы о больших данных или широкомасштабных системах в целом? 1000 столбцов не плохой дизайн, такого правила нет. Наши имена столбцов не определены заранее. Данные взяты из наблюдений, и наши пользователи определяют имена столбцов на основе данных, которые собирают данные. Итак, да, у нас есть пользователи, у которых есть тысячи вещей для наблюдения. Они могут наблюдать 100 вещей, затем они могут редактировать наблюдение и добавлять еще 500 вещей. Возможно, мы поедем с MongoDB, он поддерживает даже миллионы «столбцов». – meletis