How to Generate Schema DDL Scripts with One File Per Table using SQL Developer

I want to generate scripts for all the tables available in schema.
I want to generate separate scripts for each table available in schema and each script must contains it’s dependent objects like indexes for that table or if triggers are available the this must include in the script.
I am using SQL developer 4.0.12 version. I tried with export option but separate scripts are generating for index,triggers,tables etc.

To get this exact formatting, we’re going to take advantage of a new option in the Data Modeler extension that’s available in Oracle SQL Developer:

Oracle SQL Developer Data Modeler can now generate one file per table, with its dependent objects.

Once you import the data dictionary, you have a lot of control over exactly how the DDL is generated – and we can generate it very quickly as it’s now in the model instead of being queried/generated from the database.

Import the Data Dictionary

Do this, and walk the wizard.

This is a fancy way of saying, ‘suck objects out of the database into my model’

quick DDL in SQL Developer? data modeler doesn’t use the same mechanism as sqldev to generate DDL. The modeler does have about 100 options when it comes to generating DDL though, did you investigate them?

I’d like a way to package together my procedures that operate on a table, along with its definition, so that all concerns for that table are in one location. I’m inclined to create a Kitchen.sql that contains them. But putting DDL in stored procedure isn’t allowed. I could wrap DDL in execute blocks. Not a great idea as it’s now runtime executed and no compile checking. But not a deal breaker. An alternative would be putting KitchenProc.sql along side with KitchenDDL.sql which meets “discovery of like things is easy because they are together” design characteristics.

Thanks! I’ll take a look. Cart sounds like it’s making the deployment part easy. What I’m really after is to get the source code organized in a sensible way so the later developer can see in the source directory (which is checked into source control):
src/database/Kitchen.sql, KitchenDDL.sql, KitchenUnitTest.sql

I thought about splitting DDLs from the procedures but that didn’t seem sensible as they all have a relationship together. To avoid being too flat in directory structure could do:
src/database/Kitchen/Kitchen.sql, …
src/database/LivingRoom/LivingRoom.sql, …

And maybe Kitchen.sql will be split into .pks and .pkg. (If I can find an advantage that outweighs the disadvantage of having them split. utPLSQL, for example can do some autocompile for me, but then in this case I’ll split the test code this way.)