Yes, it makes sense, sorta, and as I said I prefer to work that way. Start with a database and then have DBIx::Class build the schema files from that, rather than the other way round. Using dbicdump you can repeatedly dump your database to schema files, as the DB schema changes, even if you add custom code to the files, since the dumper preserves your changes.

Example of a dump statement:

$ dbicdump -o dump_directory=./lib -o components='[q{InflateColumn::Da
+teTime}]' -o preserve_case=1 MyClass::MyDB::Schema dbi:mysql:MyDB:loc
+alhost:3306 -o overwrite_modifications=1 db_user db_password
[download]

(Note that the scary-looking "overwrite_modifications" refers to manual changes you may have made to the autogenerated section of the schema file (which you should never do), and not to the modifications you make to the section below the marker indicating it is safe to do so.)

---

Addendum: I will note that as a beginner in Perl and Mojo, adding DBIx to the mix is maybe making your life more difficult than it need be. If I were to suggest a choice it would be to build with the more open Dancer2 and use the simple Dancer2::Plugin::Database plugin. Then your app code can just do something like:

get '/user/:name' => sub {
    database->quick_select('users', { name => params->{name} });
};
[download]

DBIx is nice when you really need an ORM, i.e. when your app gets complex enough to merit it because you have a bunch of objects flying around.

# Database with tables related by foreign key
# route handler subclassed from somewhere or consuming a DB role
# pseudocode
get '/user/:name/hobby' => sub {
    my $user = $self->db_rs('MyDB', 'Users')->find({ name => params->{
+name} });
    return $user->hobby;
};
[download]

Hope this helps!