2 deleted 1 character in body
source | link

I have in mind to develop a Ruby on Rails app with two different databases.

In the primary SQL db - let's say MySQL, for instance - I'd keep my app items, e.g. user profiling, user-user interactions and, in general, everything that's bound to a model, anything that I already know how is made.

Now the best part: I'd like to add a secondary No-SQL db - let's say MongoDB, for instance - where I want to put other documents that I don't know which fileds they may contain, not bound to any model. End-users, while interacting with the app, should be able to add their own custom documents and create their collections, making queries and also creating views - I mean views inside the db, I'm not talking about web pages - to aggregate not-so-well-formatted records.

What do I mean for not-so-well-formatted records? For example, let's say that a user inserts a record like this one:

{ "name":"Bill", "surname":"Ball" }

and then another recordsrecord like this one:

{ "firstname":"Tim", "lastname":"Tam" }

As you can see, the fields name and firstname are meant to be the same field, while they're actually different feilds; at the same time, surname and lastname are meant to be the same, but they're different because the user did a sloppy job while inserting those records.

I'd like the app could notify the discrepancy to the user so he can choose wether to aggregate those two fields or the keep them separated; if he chooses to aggregate them, he should be able to define - in a very simple and friendly way - a view into the db, maybe applying some kind of alias to every field. Maybe even defining the type of each field, e.g. strings, dates, integers, etc. So, after the user makes few clicks, the view could look like:

{ "firstname":"Bill", "lastname":"Ball" }
{ "firstname":"Tim",  "lastname":"Tam" }

while preserving the original/raw data inside the collection. I already know how to do this with MongoDB, by the way, but still I don't know if this could be the right approach.

I don't want the user to be obliged to create any model for his data, I'd simply want to let him throw raw documents into the db and eventually autonomously "fixing" the discrepancies after, so he can continue querying his collections without worrying about those discrepancies in naming convention.

So here's my question: is this a good approach to solve my problem? I already know that I can have multiple dbs attached to my Rails app, but is this structure convenient? Or is there something better?

I have in mind to develop a Ruby on Rails app with two different databases.

In the primary SQL db - let's say MySQL, for instance - I'd keep my app items, e.g. user profiling, user-user interactions and, in general, everything that's bound to a model, anything that I already know how is made.

Now the best part: I'd like to add a secondary No-SQL db - let's say MongoDB, for instance - where I want to put other documents that I don't know which fileds they may contain, not bound to any model. End-users, while interacting with the app, should be able to add their own custom documents and create their collections, making queries and also creating views - I mean views inside the db, I'm not talking about web pages - to aggregate not-so-well-formatted records.

What do I mean for not-so-well-formatted records? For example, let's say that a user inserts a record like this one:

{ "name":"Bill", "surname":"Ball" }

and then another records like this one:

{ "firstname":"Tim", "lastname":"Tam" }

As you can see, the fields name and firstname are meant to be the same field, while they're actually different feilds; at the same time, surname and lastname are meant to be the same, but they're different because the user did a sloppy job while inserting those records.

I'd like the app could notify the discrepancy to the user so he can choose wether to aggregate those two fields or the keep them separated; if he chooses to aggregate them, he should be able to define - in a very simple and friendly way - a view into the db, maybe applying some kind of alias to every field. Maybe even defining the type of each field, e.g. strings, dates, integers, etc. So, after the user makes few clicks, the view could look like:

{ "firstname":"Bill", "lastname":"Ball" }
{ "firstname":"Tim",  "lastname":"Tam" }

while preserving the original/raw data inside the collection. I already know how to do this with MongoDB, by the way, but still I don't know if this could be the right approach.

I don't want the user to be obliged to create any model for his data, I'd simply want to let him throw raw documents into the db and eventually autonomously "fixing" the discrepancies after, so he can continue querying his collections without worrying about those discrepancies in naming convention.

So here's my question: is this a good approach to solve my problem? I already know that I can have multiple dbs attached to my Rails app, but is this structure convenient? Or is there something better?

I have in mind to develop a Ruby on Rails app with two different databases.

In the primary SQL db - let's say MySQL, for instance - I'd keep my app items, e.g. user profiling, user-user interactions and, in general, everything that's bound to a model, anything that I already know how is made.

Now the best part: I'd like to add a secondary No-SQL db - let's say MongoDB, for instance - where I want to put other documents that I don't know which fileds they may contain, not bound to any model. End-users, while interacting with the app, should be able to add their own custom documents and create their collections, making queries and also creating views - I mean views inside the db, I'm not talking about web pages - to aggregate not-so-well-formatted records.

What do I mean for not-so-well-formatted records? For example, let's say that a user inserts a record like this one:

{ "name":"Bill", "surname":"Ball" }

and then another record like this one:

{ "firstname":"Tim", "lastname":"Tam" }

As you can see, the fields name and firstname are meant to be the same field, while they're actually different feilds; at the same time, surname and lastname are meant to be the same, but they're different because the user did a sloppy job while inserting those records.

I'd like the app could notify the discrepancy to the user so he can choose wether to aggregate those two fields or keep them separated; if he chooses to aggregate them, he should be able to define - in a very simple and friendly way - a view into the db, maybe applying some kind of alias to every field. Maybe even defining the type of each field, e.g. strings, dates, integers, etc. So, after the user makes few clicks, the view could look like:

{ "firstname":"Bill", "lastname":"Ball" }
{ "firstname":"Tim",  "lastname":"Tam" }

while preserving the original/raw data inside the collection. I already know how to do this with MongoDB, by the way, but still I don't know if this could be the right approach.

I don't want the user to be obliged to create any model for his data, I'd simply want to let him throw raw documents into the db and eventually autonomously "fixing" the discrepancies after, so he can continue querying his collections without worrying about those discrepancies in naming convention.

So here's my question: is this a good approach to solve my problem? I already know that I can have multiple dbs attached to my Rails app, but is this structure convenient? Or is there something better?

1
source | link

Ruby on Rails: primary SQL db and secondary No-SQL db without models

I have in mind to develop a Ruby on Rails app with two different databases.

In the primary SQL db - let's say MySQL, for instance - I'd keep my app items, e.g. user profiling, user-user interactions and, in general, everything that's bound to a model, anything that I already know how is made.

Now the best part: I'd like to add a secondary No-SQL db - let's say MongoDB, for instance - where I want to put other documents that I don't know which fileds they may contain, not bound to any model. End-users, while interacting with the app, should be able to add their own custom documents and create their collections, making queries and also creating views - I mean views inside the db, I'm not talking about web pages - to aggregate not-so-well-formatted records.

What do I mean for not-so-well-formatted records? For example, let's say that a user inserts a record like this one:

{ "name":"Bill", "surname":"Ball" }

and then another records like this one:

{ "firstname":"Tim", "lastname":"Tam" }

As you can see, the fields name and firstname are meant to be the same field, while they're actually different feilds; at the same time, surname and lastname are meant to be the same, but they're different because the user did a sloppy job while inserting those records.

I'd like the app could notify the discrepancy to the user so he can choose wether to aggregate those two fields or the keep them separated; if he chooses to aggregate them, he should be able to define - in a very simple and friendly way - a view into the db, maybe applying some kind of alias to every field. Maybe even defining the type of each field, e.g. strings, dates, integers, etc. So, after the user makes few clicks, the view could look like:

{ "firstname":"Bill", "lastname":"Ball" }
{ "firstname":"Tim",  "lastname":"Tam" }

while preserving the original/raw data inside the collection. I already know how to do this with MongoDB, by the way, but still I don't know if this could be the right approach.

I don't want the user to be obliged to create any model for his data, I'd simply want to let him throw raw documents into the db and eventually autonomously "fixing" the discrepancies after, so he can continue querying his collections without worrying about those discrepancies in naming convention.

So here's my question: is this a good approach to solve my problem? I already know that I can have multiple dbs attached to my Rails app, but is this structure convenient? Or is there something better?