I agree a single blob would also work (I do that in some cases). The reason
for the map is if you need more flexible updating. I think your solution of
a map/data type works well.
On Thu, Sep 15, 2016 at 11:10 AM DuyHai Doan <doanduy...@gmail.com> wrote:
> "But I need rows together to work with them (indexing etc)"
>
> What do you mean rows together ? You mean that you want to fetch a single
> row instead of 1 row per property right ?
>
> In this case, the map might be the solution:
>
> CREATE TABLE generic_with_maps(
> object_id uuid
> boolean_map map<text, boolean>
> text_map map<text, text>
> long_map map<text, long>,
> ...
> PRIMARY KEY(object_id)
> );
>
> The trick here is to store all the fields of the object in different map,
> depending on the type of the field.
>
> The map key is always text and it contains the name of the field.
>
> Example
>
> {
> "id": xxxx,
> "name": "John DOE",
> "age": 32,
> "last_visited_date": "2016-09-10 12:01:03",
> }
>
> INSERT INTO generic_with_maps(id, map_text, map_long, map_date)
> VALUES(xxx, {'name': 'John DOE'}, {'age': 32}, {'last_visited_date':
> '2016-09-10
> 12:01:03'});
>
> When you do a select, you'll get a SINGLE row returned. But then you need
> to extract all the properties from different maps, not a big deal
>
> On Thu, Sep 15, 2016 at 7:54 PM, Dorian Hoxha <dorian.ho...@gmail.com>
> wrote:
>
>> @DuyHai
>> Yes, that's another case, the "entity" model used in rdbms. But I need
>> rows together to work with them (indexing etc).
>>
>> @sfespace
>> The map is needed when you have a dynamic schema. I don't have a dynamic
>> schema (may have, and will use the map if I do). I just have thousands of
>> schemas. One user needs 10 integers, while another user needs 20 booleans,
>> and another needs 30 integers, or a combination of them all.
>>
>> On Thu, Sep 15, 2016 at 7:46 PM, DuyHai Doan <doanduy...@gmail.com>
>> wrote:
>>
>>> "Another possible alternative is to use a single map column"
>>>
>>> --> how do you manage the different types then ? Because maps in
>>> Cassandra are strongly typed
>>>
>>> Unless you set the type of map value to blob, in this case you might as
>>> well store all the object as a single blob column
>>>
>>> On Thu, Sep 15, 2016 at 6:13 PM, sfesc...@gmail.com <sfesc...@gmail.com>
>>> wrote:
>>>
>>>> Another possible alternative is to use a single map column.
>>>>
>>>>
>>>> On Thu, Sep 15, 2016 at 7:19 AM Dorian Hoxha <dorian.ho...@gmail.com>
>>>> wrote:
>>>>
>>>>> Since I will only have 1 table with that many columns, and the other
>>>>> tables will be "normal" tables with max 30 columns, and the memory of 2K
>>>>> columns won't be that big, I'm gonna guess I'll be fine.
>>>>>
>>>>> The data model is too dynamic, the alternative would be to create a
>>>>> table for each user which will have even more overhead since the number of
>>>>> users is in the several thousands/millions.
>>>>>
>>>>>
>>>>> On Thu, Sep 15, 2016 at 3:04 PM, DuyHai Doan <doanduy...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> There is no real limit in term of number of columns in a table, I
>>>>>> would say that the impact of having a lot of columns is the amount of
>>>>>> meta
>>>>>> data C* needs to keep in memory for encoding/decoding each row.
>>>>>>
>>>>>> Now, if you have a table with 1000+ columns, the problem is probably
>>>>>> your data model...
>>>>>>
>>>>>> On Thu, Sep 15, 2016 at 2:59 PM, Dorian Hoxha <dorian.ho...@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Is there alot of overhead with having a big number of columns in a
>>>>>>> table ? Not unbounded, but say, would 2000 be a problem(I think that's
>>>>>>> the
>>>>>>> maximum I'll need) ?
>>>>>>>
>>>>>>> Thank You
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
