Web Application VS Windows Application
-
@IT-ADMIN said:
now i only need to learn well about one good ORM in order to be able to convince him, currently i'm studying doctrine2 and laravel, if i understand them well and after testing them in my test project, that time i can demonstrate to him how to use it and the benefits we can get behind using it,
No, you should NOT need to find a good ORM. That's what we are saying.
-
What you need to do is...
- Figure out if you need relational data at all. We aren't even up to the point of talking frameworks yet.
- Only look for frameworks, talking ORM means you've already missed the modern development boat, here.
-
our first model is the following, after that we gonna add more entity by the time
by the way it is only the payroll model of our application
-
as far as i can see, the modern way is not to begin with modeling, isn't it??
-
@IT-ADMIN honestly, that doesn't look like it should be relational at all. This is a prime candidate for not being relational. Who suggested relational?
-
@IT-ADMIN said:
as far as i can see, the modern way is not to begin with modeling, isn't it??
No, the modern way is not to model it at all. The framework models it for you.
-
If you do your own modelling and them try to use an ORM, that causes a ton of extra work, defeats much of the purpose of the modern systems and can easily introduce performance problems.
-
why it should not be a relational DB, ??
-
all entities are related to each other,
-
@IT-ADMIN said:
why it should not be a relational DB, ??
Because relational is not the default choice. Relational is heavy weight and slow. Extra effort, extra problems. If you don't need it, it's not good for you.
Nothing in the data that you has leverages a relational system really. It's perfect as a document.
-
@IT-ADMIN said:
all entities are related to each other,
Yes, of course, but not in a way that suggests that a relational database is valuable. You have modelled the data correctly to use a relational database for it, but a relational database is incredibly inefficient here and unnecessarily strict. You aren't getting any benefits from the relationships. And as another thread covered... all data is relational. By the "rules of relationships" every CSV is relational data. That the data is "relational" is meaningless. It's that it is not useful in a relational database that matters. All databases have relationships.
-
@scottalanmiller said:
@IT-ADMIN said:
why it should not be a relational DB, ??
Because relational is not the default choice. Relational is heavy weight and slow. Extra effort, extra problems. If you don't need it, it's not good for you.
Nothing in the data that you has leverages a relational system really. It's perfect as a document.
lol, you can't be serious, how we can know a specific card to whom it belong,
i'm really in a state of lose, -
@IT-ADMIN said:
lol, you can't be serious, how we can know a specific card to whom it belong,
i'm really in a state of lose,Card meaning, like passport? Well it depends what you use. But if you use a document database like MongoDB, you would either know that it was theirs because it would be contained within their document. Or you would have a key that associates them.
You are confusing the idea of data that relates to other data and the usefulness of a relational database. They are rather different things.
-
the project is under construction, the entities will be added to this model by the time
-
Look at the post that you just wrote. The post is associated with you, right? The post and you have a relationship. Yet MangoLassi has no relational database. So clearly relationships in data are not lost by not using a relational database. You don't choose a relational database model because your data has relationships. Remember most systems should not be relational, but all data has relationships.
-
@IT-ADMIN said:
the project is under construction, the entities will be added to this model by the time
But just like the passport, you would just add them in the user's document. Your data is really ideal for a document database.
-
really i have to learn about this point, because we have learned from the time of university one type of DB, relational DB, what are you saying is the first time i hear it, i have to take some time to contemplate about this, i will check my papers and i will resume
to be continued ...
-
@IT-ADMIN said:
really i have to learn about this point, because we have learned from the time of university one type of DB, relational DB,
I've was building NoSQL systems for the Fortune 100 in the late 1980s while still in middle school. They aren't new. But the popular use of them is pretty new for the mainstream.
NoSQL has been a major topic this past decade. It's huge. It's the most basic consideration in data storage today. If you have heard of MongoDB, Cassandra, Redis, LocalDB (part of MS SQL Server), CouchDB, LayerDB, DynamoDB, MS Azure Tables, MS Azure DocumentDB, Freebase, InfinityDB, ElasticSearch, Amazon SimpleDB, Solr, Dynamo, Oracle NoSQL, Riak, BDB, Memchache, BigTable and hundreds of others... those are not relational.
NoSQL is so important that MS SQL Server, PostgreSQL, DB2, Oracle and many other traditional DRBDM offer NoSQL options under the hood, too.
-
@IT-ADMIN said:
what are you saying is the first time i hear it, i have to take some time to contemplate about this, i will check my papers and i will resume
Several of the projects in this community this past week have been non-relational. All logging projects like ELK and Graylog use NoSQL databases, for example.
-
And of course systems like Google were totally dependent on non-relational technology to make them plausible.
