I can't find any information about connecting to mongodb in the documents of sqlalchemy and google search.
Is it possible to use mongodb with sqlalchemy? Thanks.
as per sql alchem desc you cannot use it:
SQLAlchemy considers the database to be a relational algebra engine,
not just a collection of tables. Rows can be selected from not only
tables but also joins and other select statements; any of these units
can be composed into a larger structure. SQLAlchemy's expression
language builds on this concept from its core.
SQLAlchemy is most famous for its object-relational mapper (ORM), an
optional component that provides the data mapper pattern, where
classes can be mapped to the database in open ended, multiple ways -
allowing the object model and database schema to develop in a cleanly
decoupled way from the beginning.
The main goal of SQLAlchemy is to change the way you think about
databases and SQL!
You may use MongoAlchemy instead.
Related
Why can I not use regular SQL queries like select *from student (assuming there is a table called student) in MongoDB, although they say it is Not only SQL (NoSql)?
SQL is a domain-specific language used in programming and designed for
managing data held in a relational database management system (RDBMS)
Wouldn't it be quite confusing to use such a specific language to query data from a DBMS (MongoDB) that is structurally different from RDBMS, where there is no concept of table, rows and columns, where joins don't exist, where you can nest documents into other documents following no defined schema, and so on?
The point is that the difference between SQL and Mongo query language is not just the syntax, it is also the semantics. A Mongo query does not say the same thing of a SQL query just in a different language, it says a different thing at all.
Sure you can find a direct Mongo translation for basic SQL query, like a simple SELECT item, status from inventory WHERE status = "A" but how would you translate a JOIN to Mongo, or how would you query a nested document using SQL?
I'm not sure I fully understand the question.... But I'll give it a go.
NoSQL is a non-relational database and stands for "Not only SQL"... As for not being able to use it that is because MongoDB has their own terminology and such.
In MongoDB terms a collection is the same as a table. A collection is a grouping of MongoDB documents (A document is a record in MongoDB collection that is the basic unit of data in MongoDB)
In order to translate your statement
select *from student
to MongoDB we would use
db.student.find()
Notice the different syntax in statements. They each have their use case it is just all finding which one fits yours. There are numerous differences between the two beyond syntax such as schema, architecture and how they work.
For more information on this see the following link:
MongoDB terminology versus SQL
Is there any way to create models from MongoDB Database like Loopback has model discovery to reverse engineer database schemas into model definitions.
Because mongoDB database model is flexible it is not possible or not practical to create data model from it. Let me explain it this way. In SQL we create tables and columns manually or programmatically which does not change overtime. On the other hand in mongoDB you do not need to create tables and fields, when you invoke insert function on mongodb the data is stored in document model structure, which can be change over time depending on the data submitted for the next insertion.
Does mongodb have some analogue of SHOW CREATE TABLE in mysql which shows create query for collection?
Or can I create another collection like existing one with all settings?
There no analogs for SHOW CREATE TABLE.
But maybe you will find a some usufull functions there https://docs.mongodb.com/manual/reference/command/nav-administration/
For example the information about indexes you can retrieve with getIndexes function.
Create the indexes you can via createIndexes function.
Example:
var indexes = db.collection.getIndexes();
db.collection.createIndexes(indexes);
Use MongoDB compass : Visualize, understand, and work with your data through an intuitive GUI.
https://www.mongodb.com/products/compass?_bt=208952627176&_bk=mongodb%20compass&_bm=e&_bn=g&utm_source=google&utm_campaign=Americas_US_CorpEntOnly_Brand_Alpha_FM&utm_keyword=mongodb%20compass&utm_device=c&utm_network=g&utm_medium=cpc&utm_creative=208952627176&utm_matchtype=e&_bt=208952627176&_bk=mongodb%20compass&_bm=e&_bn=g&jmp=search&gclid=Cj0KCQiAmITRBRCSARIsAEOZmr6S3Hw_plZO3dbZS7UGwhU2hS-EGz2vB1SR5tAuMOGd-6j82FkQunIaAgDQEALw_wcB
There is no good answer to this question because the schema involved when dealing with schema-less databases like MongoDB is dictated by the application, not the database.
The database will shove in whatever it is given as there is nothing enforcing a consistent document structure within a given collection, even though all access to the database should be controlled through some kind of wrapper. In conclusion, the only place you should look at for the schema is your model classes.
i have a question for the performance in meteorJS. Before i used meteorJS is always wrote my Applications in PHP and MySQL. In MySQL i always created a lot of tables with many connections betweens them.
For example:
Table User
id;login;password;email
Table User_Data
user_id;name;age
My questions is now how i have to design my MongoDB collections. Its nice that the collection are build like js objects so i dont have to predesign my tables and can always easy change the collumns. But is it better to combine all data to one collection or to several collections ?
For example:
Table User
_id;login;password;email;data:{name;age}
Is it better or worse for the performance ? Or is it the wrong pattern to design MongoDB Collections ?
The question mainly about MongoDB data modeling. What you'll learn applies to MongoDB used with Meteor or with anything else.
http://docs.mongodb.org/manual/data-modeling/ talks about data modeling with MongoDB and is a good introduction.
In your particular case, you can read more about how to avoid JOINs in MongoDB.
What would be the equivalent of ERD for a NoSQL database such as MongoDB?
It looks like you asked a similar question on Quora.
As mentioned there, the ERD is simply a mapping of the data you intend to store and the relations amongst that data.
You can still make an ERD with MongoDB as you still want to track the data and the relations. The big difference is that MongoDB has no joins, so when you translate the ERD into an actual schema you'll have to make some specific decisions about implement the relationships.
In particular, you'll need to make the "embed vs. reference" decision when deciding how this data will actually be stored. Relations are still allowed, just not enforced. Many of the wrappers for MongoDB actually provide lookups across collections to abstract some of this complexity.
Even though MongoDB does not enforce a schema, it's not recommended to proceed completely at random. Modeling the data you expect to have in the system is still a really good idea and that's what the ERD provides you.
So I guess the equivalent to the ERD is the ERD?
You could just use a UML class diagram instead too.
Moon Modeler supports schema design for MongoDB. It allows users to define diagrams with nested structures.
I know of no standard means of diagramming document-oriented "schema".
I'm sure you could use an ERD to map out your schemata but since document databases do not truly support--or more importantly enforce--relationships between data, it would only be as useful as your code was disciplined to internally enforce such relationships.
I have been thinking about the same issue for quite some time.
And I came to the following conclusion:
If NoSQL databases are generally schemaless, you don't actually have a 'schema' to illustrate in a diagram.
Thus, I think you should take a "by example" approach.
You could draw some mindmaps exemplifying how your data would look like when stored in a NoSQL DB such as MongoDB.
And since these databases are very dynamic you could also create some derived mindmaps to show how the data from today could evolve in time.
Take a look at this topic too.
Confusion about NoSQL Design
MongoDB does support 'joins', just not in the SQL sense of INNER JOIN (the default SQL join). While the concept of 'join' is typically associated with SQL, MongoDB does have the aggregation framework with its data processing pipeline stages. The $lookup pipeline stage is used to create the equivalent of a LEFT JOIN in SQL. That is, all documents on the left of a relationship will be pass through the pipeline, as well as any relating documents on the right side of the relationship. The documents are modified to include the relationship as part of the new documents.
Consequently, I postulate that Entity Relationship Diagrams do have a role in MongoDB. Documents are certainly related to each other in the db, and we should have a visualization of these relationships, including the cardinality relationship, e.g. full participation, partial participation, weak/strong entities, etc.
Of course, MongoDB also introduces the concept of embedded documents and referenced documents, and so I argue it adds additional flavor to the model of the ERD. And I certainly would want to see embedded and referenced relationships mapped out in a visual diagram.
The remaining question is so what is out there? What is out there for Mongoose for NodeJS? Mongoid for Ruby? etc. If you check the respective repositories for their corresponding ORMs (Object Relational Mappers), then you will see there are ERDs for them. But in terms of their completeness, perhaps there is a lot to be desired and the open source community is welcome to make contributions.
https://www.npmjs.com/package/mongoose-erd
https://rubygems.org/gems/railroady