Like the title says i am looking for an ORM that supports hierarchical data.
For example i will need to represent a relation like this (category with subcategories and so on...):
CREATE TABLE "category"
(
"id" SERIAL PRIMARY KEY,
"parent" INTEGER NULL DEFAULT NULL REFERENCES "category" ("id")
"name" VARCHAR(50) NOT NULL UNIQUE,
"description" VARCHAR(100) NOT NULL,
"sort_order" INTEGER NULL DEFAULT NULL,
);
Is there any one that can do that?
You should check out sails.js. Their Waterline ORM has support for dozens of databases and has excellent relational support, and it has a huge community surrounding it.
From the docs:
You can do all the same things you might be used to (one-to-many,
many-to-many), but you can also assign multiple named associations
per-model (for instance, a cake might have two collections of people:
"havers" and "eaters"). Better yet, you can assign different models to
different databases, and your associations/joins will still work--
even across NoSQL and relational boundries. Sails has no problem
implicitly/automatically joining a MySQL table with a Mongo collection
and vice versa.
Related
I am very new to cosmosdb(documentdb), while going through the documentation I keep on reading one thing repeatedly that documentdb is schema free but I feel like collection in analogous to schema and both are logical view.
Wikipedia defined schema as 'The term "schema" refers to the organization of data as a blueprint of how the database is constructed'. I believe collection is also same it's the organization of document, stored prcedure, triggers and UDF.
So my question is, how schema is different from collection?
Collections really have nothing to do with schema. They are just an organizational construct for documents. With Cosmos DB, they serve as:
a transaction boundary. Within a collection, you can perform multiple queries / updates within a transaction, utilizing stored procedures. These updates are constrained to a single collection (more specifically, to a single partition within a collection).
a billing/performance boundary. Cosmos DB lets you specify the number of Request Units (RU) / second to allocate to a collection. Every collection can have a different RU setting. Every collection has a minimum cost (due to minimum amount of RU that must be allocated), regardless of how much storage you consume.
a server-side code boundary. Stored procedures, triggers, etc. are uploaded to a specific collection.
Whether you choose to create a single collection per object type, or store multiple object types within a single collection, is entirely up to you. And unrelated to the shape of your data.
The schema of relational databases is slightly different from the schema of document databases. In simple terms, a relational database is stricter than that of a document schema. In other words, records in an RDBMS table must strictly adhere to the schema, where as we have some amount of flexibility while storing a document into a Document collection.
Conventionally a collection is a set of documents which follows the same schema. But document DBs don't stop one from storing documents with different schema in a single collection. It is the flexibility it gives to the users.
Let us take an example. Let us assume we are storing some customer information.
In relational DB, we might have some structure like
Customer ID INT
Name VARCHAR(50)
Phone VARCHAR(15)
Email VARCHAR(255)
Depending on customer having an email or phone number, they will be recorded as proper values or null values.
ID, Name, Phone, Email
1, John, 83453452, -
2, Victor, -, -
3, Smith, 34535345, smith#jjjj
However in document databases, some columns need to appear in the collection, if they don't have any values.
[
{
id: "123",
name: "John",
phone:"2572525",
},
{
id: "456",
name: "Stephen",
},
{
id: "789",
name: "King",
phone:"2572525",
email:"king#asfaf"
}
]
However it is always advisable to stick to a schema in document db's even if they provide flexibility to store schema-less documents to a collection for maintainability purposes.
I'm learning how the data model works in Cassandra, what things you can do and what not, etc.
I've seen you can have collections and I'm wondering if you can search for the elements inside the collection. I've seen that you can look for one element with contains, but if you want to look for more than one you need to add more filters, is there any way to do this better? is it a bad practice?.
This my table definition:
CREATE TABLE data (
group_id int,
user timeuuid,
friends LIST<VARCHAR>,
PRIMARY KEY (group_id, user)
);
And this what I know i can use to look for more than one item in the list:
SELECT * FROM groups where friends contains 'bob' and friends contains 'Pete' ALLOW FILTERING;
Thank you
Secondary indexes are generally not recommended for performance reasons.
Generally, in Cassandra, Query based modelling should be followed.
So,
That would mean another table:
CREATE TABLE friend_group_relation (
friend VARCHAR,
group_id int,
<user if needed>
PRIMARY KEY ((friend), group_id)
);
Now you can use either IN query (not recommended) or async queries (strongly recommended, very fast response) on this table.
You can follow 2 different approaches
Pure cassandra: use a secondary index on your collection type as defined here documentation
You may also be able to use Solr and create a query against solr to retrieve your entries. Although this may look like a more complicated solution because it will require to use an extra tool it will avoid using secondary indexes on Cassandra. Secondary indexes on Cassandra are really expensive and based on on your schema definition may impact your performances.
Ok, I edited to make it clear.
I have sort kind of problem here. I cannot find the best way to do this:
I have a "table" at my MongoDB with my Mongoose Model like that:
var machineSchema = new Schema({
uuid : String,
data : String
});
So the UUID is my machine UUID. I can have something like this on the database:
{"uuid":"bla1","data":"RAM 1024MB"},
{"uuid":"bla1","data":"LINUX"},
{"uuid":"bla1","data":"CPU: Xeon"},
{"uuid":"bla2","data":"RAM 512MB"},
{"uuid":"bla2","data":"LINUX"},
{"uuid":"bla2","data":"CPU: Pentium Dual Core"}
What I want to do is, having two UUIDs (like bla1 and bla2) find what they have in common (data). So it should return:
{"uuid":"bla1","data":"LINUX"},
{"uuid":"bla2","data":"LINUX"}
or just
{"data":"LINUX"}
I could do two queries for bla1 and bla2 and them compare manually, but I think it has a better way to do that. I'm not used to Mongoose queries, there is anyway to do it? On MySQL I would do a Query with two subqueries only selecting the results that field1 matches between two. On Mongoose how should I do that?
Thanks!
It sounds like you require classic SQL 'join' functionality.
Unfortunately MongoDB (as well as most NoSQL databases) do not support joins, the functionality is more geared towards dealing with separate entities rather than sets.
I am using node and planning to use redis to store data [data will be in the SQL or oracle table format with many fields like ID, name, City, Marks, etc].
Found that we can store only key and value in redis with three data structures [in list, set or sorted set].
Is it possible for me to store like Table name [Key name] : Details
and values like ID : 1, Name : john, Country:Russia,
ID : 2, Name : Rose , Country:US , etc.
Is there any other data structure apart from list, set and sorted set in redis?
Yes. See the docs.
http://redis.io/topics/data-types
You also have the Hash data structure...
Database tables are used to store Entities. A loose definition of an Entity is something that has a unique primary key. In Redis, Entities are usually stored using Hash data structure, where columns in the database become fields in the Hash. The primary key is stored in the key of the hash.
Database tables also store non-entities, such as relationships between Entities. For example one-to-many relationship is typically done using a foreign key. In Redis, such relationships can be modeled in Sets, Lists or SortedSets.
I'm new to NoSQL and BigTable, and I'm trying to learn how I can (and if should) use super columns to create a BigTable friendly schema.
Based on this article about NoSQL data modeling, it sounds like instead of using JOIN-centric RDBMS schemas, I should aggregate my data into larger tables to de-normalize where possible. Based on that, here's a simple schema I envisioned for a 'User', which I'm trying to create for Cassandra:
User: {
KEY: UserId {
name: {
first,
last
},
age,
gender
}
};
The above column family (User), whose key is a 'UserID', is composed of 3 columns (name, age, gender.) Its column 'name' would be a super column who is composed of 'first' and 'last' columns.
So what I'm asking is:
What does the CQL 3.0 look like to create this column family 'User' with the 'name' super column within it? (Update: This doesn't appear possible.)
Should I be using super columns (like this)? Should I be using something else?
What's an alternative way of representing this schema?
How do I represent a list of values in a table/column family?
Here are some useful links about this that I found, but that I don't quite understand clearly enough to answer my question:
Create a Cassandra schema for a super column with metadata
Cassandra: How to create column in a super column family?
Modeling relational data with Cassandra
Thanks!
Update:
After alot of research, I'm learning a few things:
You cannot create super columns using CQL; there might be other mechanisms to do so, but CQL does not appear to be one of them.
Syntax for SQL 3.0 seems to be drifting from a 'COLUMN FAMILY'-centric approach towards SQL-like 'TABLE' based syntax.
Changed my questions accordingly.
Should I be using super columns (like this)? Should I be using
something else?
You can use that data model that you suggested. But generally it is not recommended for these reason as mentioned in the link.
I'll also note that use of super columns is generally discouraged as
they have several disadvantages. All subcolumns in a super column
need to be deserialized when reading one sub column and you can not
set secondary indexes on super columns. They also only support one
level of nesting.
Hence consider these reasons for your situation.
What's an alternative way of representing this schema?
You can try using composite columns. Read here for more information. Or you can probably just use standard column family, I think standard cf will be suitable for your situation. For example, following suggestion:
User : {
key: userId {
columnName:firstname
ColumnName:lastname
ColumnName:age
ColumnName:gender
ColumnName:zip
ColumnName:street
}
..
};
How do I represent a list of values in a table/column family?
It is possible to store the list in a BytesType in the cf. Or you can probably break the list into individual element and store as CompositeType.