Please help us help you and fill where relevant:
Your LimeSurvey version: 7.0.7+260729 
Own server or LimeSurvey hosting: Own server
Survey theme/template:
Database: MariaDB 10.11.18
PHP: 8.4.22
==================
Hello.
I have a survey with one Ranking type question.
It contains 71 choices.
As I understand from the information I found online, Limesurvey should natively create a separate database column for each rank position rather than a single combined text string, but in my case all of the answer codes are stored in a single column, each rounded by " and separated by comma.
Is it by design or am I missing some configuration?
I would like to have them separated in single columns.
Thanks.

I don't think you missed a configuration step. With LimeSurvey 7 the database structure was refactored.  The ranking question seems to be modified. There are already some issues reported in the bugtracker.
I recommend to submit a bugreport too and post a link here.
bugs.limesurvey.org/bug_report_page.php

I have the feeling that we will see more people having issues with the ranking question type.
 

This is not a bug, no need to report anything.
The storage of the ranking question was modified.

The problem was that if you had 40 items to rank and the user should only pick and rank 3 of them, then the response table would contain 37 unused empty fields.

Therefore we decided that the responses for one ranking question are now stored in one column as JSON data.
For evaluation you usually pull all data anyway, and all modern DBs support JSON queries directly, so this was the best way to go.

c_schmitz wrote:

Therefore we decided that the responses for one ranking question are now stored in one column as JSON data.
For evaluation you usually pull all data anyway, and all modern DBs support JSON queries directly, so this was the best way to go.

 

I wasn't aware that most users are using databases for analyzing responses. I had the impression that many stay inside LimeSurvey. And the more sophisticated users export the data files based. Some fiddle with Excel and others with SPSS and R.

To change the existing ranking question type to save into one field via JSON is brave and will break the existing workflows.
I have never seen a SaaS survey tool doing such a change. Since most SaaS tools are not opensource they might doing stuff similar inside but a filesbased export with a field in JSON. I haven't seen that in any survey tool.  That will be a hot topic in the forum once the adoption rate of LS7 will rise. 

The statistics for the ranking question looks in LS 7.07 like this (one response):


Looks like nothing is there. Is statistics aware of the JSON data?

The problem was that if you had 40 items to rank and the user should only pick and rank 3 of them, then the response table would contain 37 unused empty fields.

I'm probably misunderstanding something, but wasn't it the whole point of existence for Maximum columns for ranking (max_subquestions)'s setting?
As I read in the manual ( www.limesurvey.org/manual/Question_type_-_Ranking ):
This option limits the number of columns created in the database (more precisely, in the answers table). If you give a value lower than maximum answers option, then this attribute will represent the upper limit of the maximum choices a respondent can make.

So, in my case, if I have 71 choices but decide the user should pick only 3, I would have set Maximum columns for ranking to 3 and it should have created only 3 columns in my database, consequently allowing the user to only pick those 3 choices.
Isn'it?

Yeah, but the problem was that the maximum answers option setting was still editable, and when users changed during a running survey, the whole survey broke, on top of using too many columns when users need to rank alot of items.

The new solution is much more flexible, usese only one field thus allows in general for bigger surveys, does not break, even if you decide to change the maximum responses and on export/statistics the data still looks the same (except for the changed field names, but that also affect all other fields).

Looks like nothing is there. Is statistics aware of the JSON data?
 

I cannot reproduce that. For me it is showing the statistics just fine, even with only one response.

Hallo Carsten,

danke für die Erklärung des Storage-Wechsels bei Ranking-Fragen – die Motivation (JSON statt 37 leerer Felder) leuchtet mir ein, das ist eine sinnvolle technische Entscheidung.

Was mich beschäftigt: Das ist ein klassischer Breaking Change für alles, was direkt auf die Response-Tabellen zugreift – eigene Reports, ReportPlugin-Implementierungen, Auswertungsskripte, BI-Anbindungen. Wer heute Code gegen das alte Spalten-Layout geschrieben hat, merkt das erst beim nächsten Update, wenn die Auswertung plötzlich falsche oder leere Ergebnisse liefert.

Meine Frage: Gibt es außer dem Changelog einen Kanal, über den solche strukturellen Änderungen am Datenmodell im Voraus angekündigt werden – z. B. eine Migration-/Breaking-Changes-Sektion im Manual, ein Dev-Mailing-List-Post vor dem Release, oder ein Label im Issue-Tracker, das man abonnieren kann? Für Leute, die auf der DB-Ebene arbeiten, wäre eine Vorankündigung mit Zeitpunkt und Übergangsempfehlung sehr hilfreich, statt die Änderung erst beim Auswertungsfehler zu entdecken.

Betrifft die Änderung auch die 6.x?

I never liked the approach of saving various codes into one column. Quite a few survey tools store multipunch questions like this as well, never understood why, because it is quite inconvenient for simple analysis in Excel for example.

However, I understand the reasoning behind it, as this can save a lot of database columns.

I assume this approach has not been chosen for multipunch questions in Limesurvey 7, I guess? Still one column per response option with "Y" if ticked, I guess?

I really need to find some time to install LS7.

holch wrote:

I never liked the approach of saving various codes into one column. Quite a few survey tools store multipunch questions like this as well,

Interesting, what tools do that?

holch wrote:

Still one column per response option with "Y" if ticked, I guess?

Correct, still one column per subquestion.

Wonder when the database refactoring will allow answer relevance.

Can't remember which tools, sorry. Has been a while.

But I also had a lot of requests from clients that wanted the multipunch quesitons in this format, in one column, seperated by comma. So this must be a thing.

@c_schmitz, I second bismark's statement that it would be very helpful to be able to check for such changes somewhere.
Currently, breaking changes are implemented at minor versions. That's not a very good approach.

As for the ranking type adjustments: How does this affect the data export (e.g. CSV or Excel)? Will there be a single column with JSON details within the cells?
That could be tricky to analyze.

Mazi wrote:

Will there be a single column with JSON details within the cells?

Like this