Importing Seed Data? Migrating from MySQL?

[Fireproof Socks]

I cannot find a full example of how data should be imported.  I'm familiar with web development where seed data is injected into a database either to prepare it for use, e.g. by providing a standard list of countries, languages, or currencies.  Firebase seems to have neglected attention to mainstream dev practices (imo).

This post https://www.firebase.com/blog/2014-08-12-switching-to-firebase.html is unfortunately somewhat confusing.  It's not clear, for example, how the concept of "collections" (i.e. "tables") is inferred, nor is it clear how the ids are considered.  A far more useful example would require importing records from a relational database (e.g. MySQL) so the reader can juxtapose the more common data table with the JSON structure that Firebase will consume.  

Can someone give a more clear example on how to structure "seed data" for use in Firebase (e.g. using a common example such as countries, languages, or timezones) so as to cut down on the "fiddle-time" required by would-be adopters?  

Thanks.

[Jacob Wenger]

Hey there,

Sorry for the delay in responding here. Hopefully I can give you some good pointers that will make it worth the wait.

Since Firebase has a NoSQL datastore, it is naturally going to be different from your traditional SQL datastore. Generic posts on migrations from NoSQL to SQL (I found a bunch just from Googling) most likely apply for Firebase. But in general, instead of tables like we have in the SQL world, with Firebase you have nodes. A quick migration would then be to convert every table in your SQL database to a node in your Firebase database. Foreign keys would be represented by using a list of IDs into another node in your Firebase database. You can even enforce schema (this is an integer versus this a string less than 100 characters long), using our Firebase Rules. So you can make your NoSQL database behave very much like a SQL one.

One thing to note is that doing joins on a NoSQL database is not straightforward. If there is a query you'd like to do which involves a join, it is sometimes best to create a new node which duplicates the data for both items being joined. You should feel comfortable doing this. Data storage is cheap, but query operations are not.

As for your request for a 'clear example on how to structure "seed data" for use in Firebase,' what kind of example are you looking for? If you can give me a specific use case, I'd be happy to put something together for you. I know you mentioned countries, but what exactly do you want to store with regards to countries?

Finally, you may find our guide on structuring data useful.

Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/95bc1413-0d2f-4f37-9726-6559de737d40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.