sgelbart/gist:6a37a8216aa8f1fa406b

## gistfile1.txt
**STATIC TABLE SEEDS**

problem
There's no elegant way for seeding application data that you want versioned and mirrored on all our servers. You can create traditional seeds but you end up reseeding all your application data each time (which is annoying with large tables) or you have to do some wonky work arounds for each server.

characteristics of STATIC tables
- table data should match per server, the same way file data does
- data should never be added by users
- code data is dependent upon
- there should not be any coupling based on this data, e.g., it should not send any alerts/messages that would depend upon “create” events etc

ideal procedure
- you can modify the table directly or via an admin interface (you could even create your own backend admin panel, just remember, no critial couping that alters other tables)
- once you've QAed everythign and know it's how you want it, you run a command
-- the command exports the table (I like to do it as json because it's easiest to parse and read but could be CSV or SQL too)
-- the command updates the timestamp somewhere to indicate that it was regenerated
-- you can then version the file the same way you would any other
- when another dev pulls the code, they run php artisan migrate (or you can create another command, but I think it's ok to hook this into migrate...I think there's an event you can use)
-- there's a table in the dabase "st_migrations" (st = static table) maybe, that has the timestamp for the last time the table was updated
-- if the timestamp is newer, then run the migration

Questions
- Why even put the data in the database? - Laravel and other frameworks seem like they're designed to have database driven data. You'd basically have to rewrite the ORM to place nice with file content, especially where you want to do things with joins etc. Not saying you can't but when you write it it'll end up being much less full featured
- What are use cases for this? - A great use case are static tables like roles, badges, countries, CMS page content, etc. Anything that's only going to be touched by a developer or an advanced admin.
	STATIC TABLE SEEDS

	problem
	There's no elegant way for seeding application data that you want versioned and mirrored on all our servers. You can create traditional seeds but you end up reseeding all your application data each time (which is annoying with large tables) or you have to do some wonky work arounds for each server.

	characteristics of STATIC tables
	- table data should match per server, the same way file data does
	- data should never be added by users
	- code data is dependent upon
	- there should not be any coupling based on this data, e.g., it should not send any alerts/messages that would depend upon “create” events etc

	ideal procedure
	- you can modify the table directly or via an admin interface (you could even create your own backend admin panel, just remember, no critial couping that alters other tables)
	- once you've QAed everythign and know it's how you want it, you run a command
	-- the command exports the table (I like to do it as json because it's easiest to parse and read but could be CSV or SQL too)
	-- the command updates the timestamp somewhere to indicate that it was regenerated
	-- you can then version the file the same way you would any other
	- when another dev pulls the code, they run php artisan migrate (or you can create another command, but I think it's ok to hook this into migrate...I think there's an event you can use)
	-- there's a table in the dabase "st_migrations" (st = static table) maybe, that has the timestamp for the last time the table was updated
	-- if the timestamp is newer, then run the migration

	Questions
	- Why even put the data in the database? - Laravel and other frameworks seem like they're designed to have database driven data. You'd basically have to rewrite the ORM to place nice with file content, especially where you want to do things with joins etc. Not saying you can't but when you write it it'll end up being much less full featured
	- What are use cases for this? - A great use case are static tables like roles, badges, countries, CMS page content, etc. Anything that's only going to be touched by a developer or an advanced admin.