# "Structured" use of SQL backends?

**URL:** <https://support.prodi.gy/t/structured-use-of-sql-backends/1458>\
**Category:** Uncategorized\
**Tags:** database, custom\
**Created:** [April 30, 2019, 3:05pm UTC](https://support.prodi.gy/t/structured-use-of-sql-backends/1458 "2019-04-30T15:05:28Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![ines](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ines/32/3_2.png) [@ines](https://support.prodi.gy/u/ines)\
**Post date:** [April 30, 2019, 4:16pm UTC](https://support.prodi.gy/t/structured-use-of-sql-backends/1458/2 "2019-04-30T16:16:19Z")

</div>

This is a good question! Ultimately, Prodigy is pretty agnostic to _what_ you pass around in the task dictionary. There are some conventions, like the key `"label"` or `"spans"` in some built-in recipes and interfaces, but most of it is up to you. In the default database model we ship with Prodigy, we tried to make fewer assumptions about what the example data means and how to translate it to a database schema. When we built Prodigy, we didn’t want to make any decisions here that’d be very difficult to reverse and potentially lock users in and cause migration issues down the line. Instead, we focused on making the `Database` handler fully customisable.

If you do have more specific requirements (or opinions on how you want your database to be structured), Prodigy lets you pass in your very own `Database` class that can take full control over how to store and retrieve the data. It just needs to exposes the methods that Prodigy expects. (Also see [this thread](https://support.prodi.gy/t/using-google-firestore-as-database-or-not/1358) for more details.)

---

_[View the full topic](https://support.prodi.gy/t/structured-use-of-sql-backends/1458)._