On 19 Jun 2017, at 10:47, Robert M. Münch wrote:
> Well, the question for me is, which approach will be faster?
> ...
Hi, answering my own question as I tried it with 5 records and 50 columns.
The JSON approach is way faster up to factor 1000.
Viele Grüsse.
--
Robert M. Münch, CEO
M:
On 17 Jun 2017, at 19:29, Igor Tandetnik wrote:
> For the first three (or any fixed N) columns, yes. But I thought you wanted a
> view that somehow automatically becomes wider or narrower as rows are
> inserted or deleted in the underlying table. I don't believe such a thing is
> possible.
On 6/17/2017 10:36 AM, Robert M. Münch wrote:
To get a traditional VIEW on this, we want to transpose the data, or create a
pivot of it. Here is a pretty simple structure of such a VIEW for the first
three columns:
For the first three (or any fixed N) columns, yes. But I thought you wanted a
On 17 Jun 2017, at 14:25, Igor Tandetnik wrote:
> By the same token, I don't believe such a query exists.
Hi, I think such a query exists, here we go:
Columns are: col_id, value, rec_id
col-1 1 1
col-1 2 2
col-1 3 3
col-1 4 4
col-1 5 5
col-1 6 6
what does this error mean and how can I fix it?java.sql.SQLException: opening
db: './MHDB.db': open failed: EROFS (Read-only file system)
On Sat Jun 17 2017 07:17:30 GMT-0500 (Eastern Standard Time), Robert M. Münch
wrote:
On 17 Jun 2017, at 14:10, Igor Tandetnik
On 6/17/2017 8:17 AM, Robert M. Münch wrote:
On 17 Jun 2017, at 14:10, Igor Tandetnik wrote:
I don't think so. The number and names of columns in the view are determined at
the time CREATE VIEW statement is executed.
That won't be a problem as we can update the VIEWs. The question is, how
On 17 Jun 2017, at 14:10, Igor Tandetnik wrote:
> I don't think so. The number and names of columns in the view are determined
> at the time CREATE VIEW statement is executed.
That won't be a problem as we can update the VIEWs. The question is, how does a
query look like that transposes the
On 17 Jun 2017, at 9:57, Wout Mertens wrote:
> And another option of course is to store all those extra columns as JSON,
> which you can query with the JSON1 extension. You can even index on the
> extracted values.
That's a very interesting idea. I'm going to check it out. So, the idea would
be
On 17 Jun 2017, at 9:53, Wout Mertens wrote:
> Could you not combine the data on the app side?
We are currently holding all data on the app side and want to get it into
SQLite to make use of it's querying features. So, that would be a step back.
--
Robert M. Münch, CEO
M: +41 79 65 11 49 6
On 6/17/2017 1:59 AM, Robert M. Münch wrote:
Hi, suppose I store my data like this:
Table A: table, column, data
Now I want to create a VIEW named A.table, with columns A.column and rows A.data
Is that possible?
I don't think so. The number and names of columns in the view are determined at
And another option of course is to store all those extra columns as JSON,
which you can query with the JSON1 extension. You can even index on the
extracted values.
On Sat, 17 Jun 2017, 9:53 AM Wout Mertens, wrote:
> Could you not combine the data on the app side?
>
> On
Could you not combine the data on the app side?
On Sat, 17 Jun 2017, 9:15 AM J Decker, wrote:
> Probably need to use some CTE expressions to tackle that.
>
> https://sqlite.org/lang_with.html
>
> On Fri, Jun 16, 2017 at 10:59 PM, Robert M. Münch <
>
Probably need to use some CTE expressions to tackle that.
https://sqlite.org/lang_with.html
On Fri, Jun 16, 2017 at 10:59 PM, Robert M. Münch <
robert.mue...@saphirion.com> wrote:
> Hi, suppose I store my data like this:
>
> Table A: table, column, data
>
> Now I want to create a VIEW named
Hi, suppose I store my data like this:
Table A: table, column, data
Now I want to create a VIEW named A.table, with columns A.column and rows A.data
Is that possible?
Background: We have one table where columns can be added/removed. We want to
use the session extension to keep track of
14 matches
Mail list logo