From Database Schema to a Developer's Starting Point

Use dbSlice to turn table fields and database types into models, classes, SQL templates, and API scaffolding—then shape the result into your own application.

Developer guide · English edition · October 2026

Starting an integration or API often involves repetitive work: checking column names, identifying keys, translating database types, declaring properties, and writing an initial data-access structure. dbSlice's Generate code tab helps with that starting work by using the selected database object's schema as a reference.

The developer remains responsible for the application. Generated artifacts provide field definitions and implementation examples; they do not define a complete system, its business rules, its permissions, or its architecture. The value is a concrete starting point that can be inspected, adapted, and incorporated into an existing project.

This guide follows the supplied screen, where the source is the SQL Server profile MASTER, the selected table is app_user, and the artifact is C# — .NET Minimal API CRUD. The options were checked against the accompanying application implementation. Availability can vary by version and license.

1. Begin with the table, then choose the artifact

The generator starts from a table, view, or query result structure. Its inputs describe an object and its fields. They do not describe an entire business application.

For these schema-based artifacts, the generation path uses metadata rather than exporting the table's records. A table with a million rows does not become a million lines of generated API code. Generation itself does not create a running API or execute the generated SQL against the database.

The database schema is a useful reference for possible fields and property types. It cannot tell the generator whether an email address is verified, whether a user may change a permission, or whether an account may be deleted. Those decisions belong to the application.

2. Read the Generate code screen

MASTER is a connection profile name in this demonstration. Target object is a naming input for the artifact, not a second database connection. Depending on the generator, the name influences classes, SQL identifiers, routes, or other generated names; inspect the result after changing it.

The preview makes the artifact available for review before it enters a project. Saving a file does not install dependencies, apply database changes, start a server, or deploy an application.

In the reviewed implementation, evaluation mode allows C# DTO, C# Model, and SQL DDL generation. Other entries can remain visible while requiring activation. Check the status shown by the installed build.

3. The 12 artifacts and where they help

Choose the smallest artifact that helps the task. A model may be enough when the immediate need is a list of fields and types. An API scaffold is useful when the next step is exploring an HTTP interface for that object.

The HTML/IndexedDB example uses browser storage; it is not a direct browser connection to the source database. The SQL outputs are generated text, and the DDL should not be treated as a complete database migration containing every relationship, index, trigger, and dependent object.

4. Example: understand the app_user fields

The synthetic app_user table used in the demonstration has eight columns. Its SQL Server definition gives the developer a concrete field inventory:

These columns are non-nullable in the demo schema. The is_active column has a database constraint restricting it to 0 or 1, but its database type is still SMALLINT. The reviewed C# generator maps this type to int; choosing a Boolean application property requires an explicit conversion decision.

Similarly, an integer foreign key does not automatically become a navigation property, an authorization policy, or a dropdown populated from another API. The schema tells you about storage. The application adds meaning and behavior.

5. Use models and DTOs as an editable field reference

The C# Model generator supplies typed properties. The DTO generator adds schema-derived attributes such as key, column, and required annotations. These are useful references, but the developer should still review naming, namespaces, nullability conventions, and validation.

For example, a developer might adapt a subset of the table into this response type:

// Developer-adapted example, not verbatim generator output.
public sealed class UserSummary
{
    public int Id { get; init; }
    public string Username { get; init; } = string.Empty;
    public string DisplayName { get; init; } = string.Empty;
    public bool IsActive { get; init; }
}

This response deliberately includes only four fields. It also uses an application-level Boolean for status. The mapping must translate the stored value into that representation. A separate create request or administrative update request may need a different field set.

Generating a class from all table columns is a discovery aid. It is not a decision to expose every column through a public API. In particular, company_id, permission_id, and created_at need explicit handling rather than automatic acceptance from every caller.

Rust follows the same principle: the generated structure is an initial type map. The reviewed Rust generator uses standard-library types, representing temporal and decimal values as strings to avoid imposing additional crates. Choose richer date or decimal types if the project requires them.

6. Mappers make assignments visible

The C# Mapper artifact creates explicit property assignments between generated model and DTO classes. This helps establish which source property supplies each destination property without adding a mapping library.

After generating it, align the namespaces and type names with the classes in your project. If the DTO has been reduced, renamed, or given a different type, update its mapping accordingly. Add any required conversion or normalization deliberately.

A property-copy method does not implement business validation. Nor should a generated mapping method be assumed to translate into database SQL when called inside a LINQ query. Verify query behavior with the data-access technology used by the project.

7. Start an API without confusing scaffolding with application design

The Minimal API option shown in the screenshot provides a starting structure for operations around the selected table. The preview includes route registration and SQL for listing, looking up, creating, updating, and deleting records.

This can help a programmer connect a table's fields to an initial API design: identify the matching key, see candidate parameters, inspect how values reach database commands, and decide where request and response types should be introduced.

The next design steps remain explicit:

• Decide which operations the application actually needs; a generic DELETE route may be inappropriate for an account lifecycle.
• Separate request and response models from the full storage shape.
• Define authentication, authorization, and company or tenant boundaries.
• Implement validation and rules such as who may assign permissions or activate an account.
• Configure the provider, dependencies, connection settings, error responses, and operational behavior for the project.
• Build and test the adapted implementation, including rejected requests and database failures.

These are part of turning a generated example into an application component. A CRUD scaffold provides initial mechanics; it does not infer the rules of account management from the name app_user.

The same expectations apply to repository, PHP, and Node.js artifacts. Review the generated setup notes and provider requirements. Support for a source database in dbSlice does not remove the target project's need for the appropriate runtime, package, or driver.

8. A practical workflow in the interface

1. Open Generate code and choose the saved source connection.
2. Click Connect, select Table, and choose app_user.
3. Confirm id as the key and review app_user under Target object.
4. Start with C# Model to inspect the fields and candidate types.
5. Click Generate and read the preview, including names and nullable fields.
6. Use Save file or Copy code to bring the artifact into the development workspace.
7. Choose C# DTO or C# Mapper if those artifacts help the project's design.
8. Choose C# — .NET Minimal API CRUD when ready to review an API starting point.
9. Adapt the generated material to the project's conventions and business rules, then build and test it.

Use a table for a straightforward first example. Views and queries can be useful for a narrower projection, but their metadata may not identify keys and relationships as clearly. Confirm the selected key and do not assume a view or joined query can be written through using generic CRUD statements.

9. Keep generation and ownership separate

Once an artifact is integrated into a project, the project's developers own its behavior. A later schema change should trigger a comparison with the existing implementation, not an automatic overwrite of custom work.

Generate a fresh reference into a separate location, compare fields and types, and apply the relevant changes through the project's review process. A new database column does not necessarily belong in an existing API response, and a changed nullability constraint may require more than a property declaration update.

Generated headers and setup examples should also be reviewed before sharing files. Keep real connection settings and credentials in the project's configuration mechanism rather than adding them to publication examples or committed source.

10. Where the generator saves work

dbSlice helps turn a database object into something a programmer can work with immediately: a visible field inventory, candidate language types, model properties, mapping assignments, and initial database-operation patterns.

That is the intended role of the generator: developer assistance grounded in the table schema. It reduces repetitive setup and provides a reference for the next implementation step. The programmer supplies the application design, behavior, and decisions that a table definition cannot express.

Scope of this guide

The artifact list and screen controls were checked against the supplied screenshot and the accompanying code-generation panel and writers. Field examples use the synthetic app_user schema from this documentation dataset. The UserSummary snippet is an illustrative developer adaptation, not a claim of exact generated output.

No API was deployed or connected to a live database to create this article. The original screenshot is used as a reference; its unrelated connection-profile names are not included in the publication. This guide documents a development workflow, without claiming that generated artifacts form a complete or production-ready system.