Please let me know how to configure TDE to combine data from different entity xml. I mean in sql while creating view we do it by specifying some criteria based on which view will be created, but not individual views and then performing joins.
To my knowledge that is not supported, and I suspect it won't be supported soon either. TDE is meant as views on individual documents. You will have to use joins at query time for now.
I recommend opening an RFE if you think you have a strong use case for the kind of views you are looking for.
HTH!
Related
I have an existing database with 10 or so tables and thousands of rows. I’m tiring of SQL and would like to add an ORM — probably either Objection or Sequelize.
Is there a good way to implement either ORM on an existing database?
It's not particularly difficult to connect Sequelize to an existing database. You just need to configure the connection and set up models.
If your previously-created tables include some attributes that don't match up to Sequelize's approach out of the box, you may need to write some extra code in your models. Again, this is fairly painless. See Working With Legacy Tables for additional information.
I have a question regarding the usage of a DocumentDB or SQL-Database.
E.g. I have categories which can have multiple child categories and so on. Every category can have multiple attributes and every attribute can have one or many values. Would it be better to use a schemaless solution like a DocumentDB because I could add new sub categories etc. with no effort or is it better to stick with a schema and use a SQL-Database.
Many thanks in advance.
As #DavidMakogon said, there is not a standard & absolute right answer, it just up to you and up to application scenario. For this current needs to store a tree structure of categories with attributes, it's simple to design database schema & develop application for both without any addition condition like data volume and concurrency, etc, and both are good.
Consideration for others, there are two documents may help analyzing the features which you may need to use in your application or more suitable for your scenario, to make your choice.
MongoDB vs MySQL: Comparison Between RDBMS and Document Oriented Database, it's very similar for comparision between DocumentDB and SQL Database.
10 things never to do with a relational database, I think the advantage of RDBMS is as well known and be suitable for which scenario, but NoSQL's not.
Hope it helps.
There are two tables such as student and class:
SELECT student.name, class.subj
FROM student
INNER JOIN class
ON student.class_id = class.class_id;
In sql is ok, but in mongodb,
I know the MongoDB does not support joins,
but I don't want put in one collection,
I want to put in 2 collections and query it and return in one data.
reason that I want to do like this, please see this
so how can I do?
Currently Mongodb does not support cross collection requests and AFAIK there is no plan to do such a functionality. It differs with the whole concept of document based databases.
We faced same issue with Mongodb earlier working with Nodejs project. The solution for us was to put subdocuments into another collection with a reference to parent document by _id parameter of Mongodb. Large part of it was handled by Mongoose ORM, but in its core it still will do two different requests - one for retrieving parent document and another for retrieving all children where parent document will still have a parameter array with list of _id of all its children.
This is a difference in schema design pattern between SQL and NoSQL. In SQL the schema is fixed and changing it is sometimes painful, but you benefit from this fixed schema by ability to do complex requests. In NoSQL there is no fixed schema, all schema is in your head (and perhaps documentation) and you yourself need to follow it, but this provides you a good speed on database level.
UPDATE: After all we ended up with merging two collections into one. There still were some problems with quering subdocuments from parent document, but it was pretty easy and did not change much for us. I would recommend you looking into this rather than splitting into two separate collections. it also primarily depends on the workflow with your DB, will you be doing more read queries or more write queries? With NoSQL schema you need also consider those points. If more reading - single collection is a way to go.
I inherit a project of a program that configures devices via ethernet. Settings are stored in the database. The set of settings is constantly changing as devices are developing so there's a need for a simple schema change (user must be able to perform this operation).
Now, this simplicity is achieved by the XSD-scheme (easy readable and editable), and the data is stored as XML. This approach also satisfies the requirement of the use of various database engines (MS SQL and Oracle are currently supported).
I want to move database structure to the relational model. Are there any solutions which are as easy-to-change as described one while using a relational database?
I want to move database structure to the relational model.
Why?
Do you want to be able to index/query parts of the configuration, or be able to change just one part of the configuration without touching the rest?
If no, then just treating the XML as opaque BLOB should be sufficient.
If yes, then you'll have to tell us more about the actual structure of configuration.1
1 BTW, some DBMSes can "see inside" the XML, index the elemnts and so on, but that would no longer be DBMS-agnostic.
There are several solutions to your design problem.
I suggest the following;
Use a different database. Relational databases are not the best choice for this kind of data. There are databases with good support for dynamic data. One example of such a database is mongoDB, which uses JSON-style documents.
or
2. Create one (or a small set) of Key/Value table(s). You can support a hierarcical structure by adding a parent column that points to the parent key-value pair.
I wouldn't recommend changing a relational db schema on the fly as the result of a user operation. It goes against fundamental design rules for relational database design.
i mostly need to know
- views and their purpose ?
- do they increase performance of an application ?
- in what kind of cicumstance will I need to use views?
As this is homework you should probably be doing research.
A quick Google yields plenty of links, one of which is http://www.techotopia.com/index.php/An_Introduction_to_MySQL_Views.
MySQL views are essentially a way to
package up SELECT statements into
re-usable virtual tables whereby the
data can be retrieved simply by
referencing the view, rather than
having to repeat the associated SELECT
statement.
The official site documentation is quite informative and readable too.
See: the MySQL FAQ page on Views and the Using Views documentation.
Views provide an abstraction layer over your tables.
They can be used to prevent access to certain sensitive columns (such as salary).
They are often used to encapsulate logic for reporting.
in what kind of cicumstance will I
need to use views?
If you're repeatedly using the same SELECT statement that uses lots of JOINs and/or function calls, a view makes it simpler to use.