[SOLVED] Need help in understanding Appwrite DB structures for making ERD

[strange laurel]

I need help in understanding each and every part of Appwrite cloud services and their databases, collections, schema, storage, etc in order to make the Entity Relationship Diagram (ERD) for my web application.

I'm using this tool to make the ERD: https://dbdiagram.io/d

Services I have used:

• Authentication
• Databases (6 Collections)
• Functions
• Storage

[shy bay]

You can refer to https://github.com/appwrite/appwrite/blob/master/CONTRIBUTING.md#architecture-1 and https://dev.to/appwrite/30daysofappwrite-appwrite-s-building-blocks-1936

[strange laurel]

Let me check

[strange laurel]

It's kind of architechture which just shows the overview and not the things inside of each part

[strange laurel]

I just need to know about these features and need help in making the ERD

It would be better if someone gets on a call or provides me something here to help me in getting things properly

[open dock]

appwrite is just like some other sql database. But you'd just have to write your queries with its Queries API. So for the purpose of ERD diagram, make it as simple as you would make it for MySQL/MariaDB

[sharp fog]

That's microservices appwrite uses, not database

I think the best way to discover It is connecting manually to the appwrite's database and seeing what's there

[sharp fog]

Not sure, since didn't have investigated it but it's something like this:

Authentication:

• Auth users table: contains rows with users, having all the data related: unique ID, name, email, password, preferences

• Teams table: all teams with all their corresponding data

Databases:

• Database list: table containing all databases you have

• Each collection you create is a table. Every document/row has a field to associate the corresponding database and every document apart from their ID, it has all the attributes/columns you defined

Functions:

• List of all your functions and probably details associated

• Executions (not sure if that's MariaDB, influx or Redis)

Storage:

• Probably a table for each bucket or a relationship that contains documents/rows with each document ID, URL associated, etc

If I'm not grong there are additional tables to associate the user, the project and organizations from dashboard to all elements the app contains

[strange laurel]

Okay, some things we need to confirm from the Core team

I'll try an attempt and then get back here

[sharp fog]

Confirmed, seems there are more tables than the others mentioned before. Don't understand how does this affects your project

[feral musk]

She's making an Entity Relationship Diagram to illustrate the db structure.

[open dock]

Exactly, and ERD is really abstract to what database you're using. So yeah just jot down down how you wanna structure your database.

[feral musk]

Was going to say this.

An ERD is pretty much like writing pseudo-code. You use pseudo-code to explain in easy terms what a program does. Likewise, you should make your ERD based on your specifics.

I don't see why you would want to know Appwrite's internal DB design for an ERD of your app.

[sharp fog]

Yes, that's what I'm saying

What's true is that in some cases, Appwrite internal collections/tables ends being a duplication of your collections. For example, users collection (from Auth service): you can't expose it so if you make a blog-like app, you will need to create a separate collection with the database service in order to show the name of the post creator.
Same with teams API, but just the opposite: some cases you don't want to expose the email to all users in a team, so to prevent that, you need to use teams only for permissions and then creating another different table/collection to associate teams

[strange laurel]

So, as per your point, I should jot down the collections and the attributes related to it and then connect them with the users(treating Auth as db)

Am I right?

P. S. First time going to make an ERD

[strange laurel]

So, as per your point, I should jot down the collections and the attributes related to it and then connect them with the users(treating Auth as db)

Am I right?

P.S. Making ERD for the first time

[open dock]

yeah simple :)

[strange laurel]

If you don't mind checking it after it's done, it would be a great help!

[open dock]

mostly with yes you can treat auth as db. But when you're creating ERD on basis of that you've to make a copy collection of your Auth service. So as to provide any other attributes you wanna store about your auth users. Like Auth user likes color green, his/her age is 18

[open dock]

sure just drop ERD in my dm or in general channel here.

[open dock]

sure just drop ERD in my dm or in general channel here.

[strange laurel]

Hey @open dock Check it out

Link to view everything:- https://dbdiagram.io/d/647c16cc722eb7749458d798

[open dock]

can you briefly explain what is your database schema about. And I think we should hop out of this channel cause it is for appwrite questions.

[strange laurel]

Yes, I can show you

Shall I take ss and paste it here?

[strange laurel]

Hey @shy bay Need to know about the use case of key and fulltext indexes and also their differences

[shy bay]

See https://appwrite.io/docs/databases#indexes

[strange laurel]

Okay, thanks