I design my firebase structure and I'm not sure if that the right way.
Little information:
Each college has some departments.
Each departments has many courses.Courses can belong to several departments.
Each Course has some lessons. lesson can be belong to one course.
I have node of courses with all key courses and information
I have node of departments with all departments and informations.
I have node Course_Departments and Departments_courses
in addition I have courses_lectures and courses_lectures
for display each course learn by some lecturers and each lecturers teach some courses.
so my questions are:
1.How I connect the lesson to these table for example? I want to find all the lessons of the course_key1 that lecture_key2 teach?
2. using with many tables in this way can be take many time to get the data?
for UI I don't want to users to wait much for the data.
Looking at your design, I think, you are on the right track.
I'll give some possible hints of what you can take care of. When designing the structure of a Firebase database design rules of non-relational databases should be kept in mind.
One of them is denormalization. Keep the hierarchy flat! That's an important performance factor for data change listeners since all subnodes are involved. That's what you've done so far.
Relationship of entities can be achied by using the keys. Exactly as you did it in the Courses_Department node. The built-in creation of keys should be used. They should be universally unique.
Here's a good explanation when coming from relational databases.
Related
The demand is this:
a user belongs to multiple departments, and the roles in each department are different, and each role has different permissions.
The general idea is You need to build another layer of relationships on the relationship table. I wonder if there are other better designs
Before making "super improvements" follow the "natural" strategy. If something belongs to some other thing what is the pattern you "naturally" need to use?. While exist ways to "split database tables" into some more 'simple' tables (https://www.bmc.com/blogs/canonical-data-model/) there is not a complete answer as for some db engines you might need to repeat fields to cache some info. This is typical when a server allows you only a limited number of db calls per transaction.
Official recommendation from the team is, to my knowledge, to put all datatypes into single collection that have something like type=someType field on documents to distinguish types.
Now, if we assume large databases with partitioning where different object types can be:
Completely different fields (so no common field for partitioning)
Related (through reference)
How to organize things so that things that should go together end up in same partition?
For example, lets say we have:
User
BlogPost
BlogPostComment
If we store them as separate types with type=user|blogPost|blogPostComment, in same collection, how do we ensure that user, his blogposts and all the corresponding comments end up in same partition?
Is there some best practice for this?
[UPDATE]
Can you ever avoid cross-partition queries completely? Should that be a goal? Or you just try to minimize them?
For example, you can partition your data perfectly for 99% of cases/queries but then you need some dashboard to show aggregates from all-the-data. Is that something you just accept as inevitable and try to minimize or is it possible to avoid it completely?
I've written about this somewhat extensively in other similar questions regarding Cosmos.
Basically, when dealing with many different logical entity types in a single Cosmos collection the easiest option is to put a generic (or abstract, as you refer to it) partition key on all your documents. At this point it's the concern of the application to make sure that at runtime the appropriate value is chosen. I usually name this document property either partitionKey, routingKey or something similar.
This is extremely important when designing for optimal query efficiency as your choice of partition keys can have a huge impact on query and throughput performance. A generic key like this lets you design the optimal storage of your data as it benefits whatever application you're building.
Even something like tenant does not make sense as different tenants might have wildly different data size and access patterns. Instead you could include the tenantId at runtime as part of your partition key as a kind of composite.
UPDATE:
For certain query patterns it might be possible to serve them entirely out of a single partition. It's definitely not the end of the world if things end up going cross partition though. The system is still quick. If possible, limiting the amount of partitions that need to be touched for a given query is ideal but you're never going to get away from it 100% of the time.
A partition should hold data related to a group that is expected to grow, for instance a Tenant which will group many documents (which can be of different types as you have mentioned) So the Partition Key in this instance should be the TenantId. The partitioning is more about the data relating to a group than the type of data. If the data is related to a User then you could use the UserId, however many users may comment on the same posts so it doesn't seem like a good candidate for a partition key unless there is some de-normalization of the user info so it doest have to relate back to the other users directly.. if that makes sense?
Situation: In the app we have up to 1000 schools. Every school has students and students are having lessons and are joining events (and more). We need to query quick and often lessons per student, per school per date. We have 2 designs in mind, wondering the best way to proceed.
1 - design with dedicated school node
2 - design with no dedicated school node
Examples of two designs
PRO design 1
- root ref to school user after login. noo need to query on school id's
- no need to mention school id's everywhere
- no need for node lessens per school and events per school
- rules on school level
...
PRO design 2
- more flatten data, as widely advised on the internet
For most NoSQL database structures, flattening and denormalising data is the best method. And that is exactly the case with Firebase too.
When you flatten your data, you get the following advantages :-
You're mostly only downloading the minimum required amount. That leads to efficiency and cost-effectiveness.
Your downloads are much faster - specially compared to the likes of SQL join queries.
Having said that, in your particular case, I think that it really depends on how much the school affects the logged in user.
Suppose that a school is only an attribute for a student, and serves no other purpose, then the second database is the way to go. For example, if the books a student can get are independent of the school she goes to, then the second database style is more suited.
However, if a school categories students into groups that define their interaction with the database, then the first database structure is the way to go. An example of this is that a student can only get a book when its available in the school she goes to.
Regardless of your decision, I would like to commend you on the fact that you have flattened your database quite well in both your structures! And my personal suggestion would be to go with the one that is more convenient to code, read and maintain for you.
In my OLTP database I have a layout consisting of instructors and students. Each student can be a student of any number of instructors. A student can also sign up for an instructor, but not necessarily book any tuition (lesson).
In a data warehouse, how best would this be modelled? If I create a dimension table for Lessons, Instructors and Students and a fact table for the lessons students have taken then this will work when an instructor wants to see what lessons a student has taken.
However, how will an instructor see how many students are REGISTERED with the instructor but has not yet taken a lesson?
In my OLTP, I have a many to many table (InstructorStudents) that links each student with one more more instructors. In an OLAP database, this isn't appropriate.
What would be the best schema in this case? Would a many to many be appropriate in this instance? I can't store a list of which students are registered to which instructors in the student table, so I feel another dimension table is necessary but cannot work out what should be contained in it.
If a fact represents a transaction, you seem to have two different facts here: Sign ups & Lessons. There are always a lot of ways to go but, perhaps, you need two fact tables. They may have similar dimensionality except the sign-up table will have a Class dimension (class name, instructor name, etc.). The Lessons table will tie to the class dimension but, also, to a Lesson dimension (date, classroom used, etc.).
There are a few other ways to do this but they will be more difficult from a programming & reporting perspective.
You need a many to many dimensional model.
You need a factless fact table. Look at the following resource that refers to an example close to your need
http://www.kimballgroup.com/1996/09/02/factless-fact-tables/
I have company, customer, supplier etc tables which all have address information related columns.
I am trying to figure out if I should create a new table 'addresses' and separate all address columns to that.
Having address columns on all tables is easy to use and query but I am not sure if it is the right way of doing it from a good design perspective, having these same columns repeat over few tables is making me curious.
Content of the address is not important for me, I will not be checking or using these addresses on any decision making processes, they are purely information related. Currently I am looking at 5 tables that have address information
The answer to all design questions is this:
It depends.
So basically, in the Address case it depends on whether or not you will have more than 1 address per customer. If you will have more than 1, put it in a new Addresses table and give each address a CustomerID. It's overkill (most times, it depends!) to create a generic Address table and map it to the company/customer/supplier tables.
It's also often overkill (and dangerous) to map addresses in a many-to-many relationship between your objects (as addresses can seem to magically change on users if you do this).
The one big rule is: Keep it simple!
This is called Database Normalization. And yes, you want to split them up, if for no other reason because if you need to in the future it will be much harder when you have code and queries in place.
As a rule, you should always design your database in 3rd Normal Form, even for simple apps (there will be a few cases where you won't for performance or logistic reasons, but starting out I would always try to make it 3rd Normal Form, and then learn to cheat after you know the right way of doing it).
EDIT: To expand on this and add some of the comments I have made on other's posts, I am a big believer in starting with a simple design when it comes to code and refactoring when it becomes clear that it is becoming too complex and more indepth object oriented principles would be appropriate. However, refactoring a database that is in production is not so simple. It is all about ROI. It is just too easy to design a normalized database from the outset to justify not doing it. The consequences of a poorly designed database can be catastrophic and it is usually too late before you come to that realization.
Yes, you should separate the addresses to a table of their own. It's a smart thing to know to ask. The key here is that general format of addresses is the same, regardless of who it is; a customer, a company, a supplier... they all have the same fields for addresses.
What makes this worthwhile is the ability to treat addresses as an atomic element; that is, you can generalize all the functionality related to addresses and have it deal with just one table, as opposed to having to worry about it dealing with several tables, and the associated schema drift that can occur.
If you are using those addresses only within the scope of their own tables, there may be no real benefit to moving them to their own tables.
Basically, it doesn't sound like it's worth the effort.
If there's an overlap between tables (i.e. the same organization is entered in both the company and supplier tables), and the address should always be the same in both tables, then it's probably worth moving address off in to its own table and having foreign keys to it from your other three tables. That way, you only have to update it in one spot when it changes.
If the three tables are entirely independent from each other, then there's not really much to gain from moving the data to another table, so you might as well leave it alone.
I think it entirely depends on the purpose of the database. Admittedly all address information is structurally the same and from a theoretical standpoint should all be in a single table linked from the parent table by a key.
However from a performance and query perspective, keeping them in their respective tables does simplify things from a reporting standpoint.
I have a situation with my current company [logistics] where the addresses are actually logically the same - they're all locations regardless of whether they're a pickup location, delivery location, customer etc.
In my case, I'd say that they should most definitely all be in one table. But if it's looking at it from a supplier, customer, contact information standpoint, I'd say that while theoretically it's nice to have the addresses in one table, in practice it won't buy you a whole lot as the data is unlikely to be repeated.
I disagree with Dave. The many-to-many approach (Address <-> User) is both safe, and highly advantageous.
When a customer moves, the addresses in the Address table does NOT change. Instead, the new address is found in the Address table, and the customer etc. is linked to that record. If the new address isn't already in the table, it's added to it.
So do address records themselves ever change? Yes, in cases like these:
it turns out that the address has a typo
US postal service changes the street name
These are the very situations where putting all addresses in one table without repetition pays off; any other arrangement would require an annoying and repetitive data entry.
Of course, if the database is abused, then it would be safer to avoid the many-to-many relationship. But by that token, if the database is in bad hands, it's better to just print everything out, store it in a file cabinet, and verify every transaction against the paper copy. So "protection against misuse" is not a good design principle, in my opinion.