Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better DB Schema #33

Open
softbobo opened this issue Dec 5, 2019 · 3 comments
Open

Better DB Schema #33

softbobo opened this issue Dec 5, 2019 · 3 comments
Milestone

Comments

@softbobo
Copy link
Contributor

softbobo commented Dec 5, 2019

Already now it becomes apparent, that the quickly constructed DB schema will not satisfy all our (future) needs. For example in #27 we state, that sending the location alongside the event was a nice feature. That makes a new table necessary. What is necessary to optimize our DB structure? I think:

  • reconsidering our choices for the storage of dates and times
  • putting constraints on text columns
  • using an ORM - here SQLAlchemy is feasible, as mentioned elsewhere
  • introducing a location table

Also, at the moment our DB is very thin and hasn't got a lot of realations going on. Yet we should at least discuss the possibility of using a different DBMS that might suit our future needs better.

The whole proposal is to be seen as part of a bigger milestone, probably 1.0.0

@obitech obitech added this to the API milestone Dec 14, 2019
@obitech
Copy link
Member

obitech commented Dec 14, 2019

We should also look at enabling database migrations while we're at it

@softbobo
Copy link
Contributor Author

I agree on database migrations. I think it is also advisable to think about an automated backup mechanism of our data. I know that SQLite has something like this built in but am not sure how this is implemented in SQLAlchemy, if at all.

@obitech
Copy link
Member

obitech commented Dec 16, 2019

I think it is also advisable to think about an automated backup mechanism of our data.

I agree. But that is probably more like an "operations problem" which we need to discuss in a different step/issue as it's independent of using SQLAlchemy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants