Relational database application
The best way to start is to figure out "user stories" (or "use cases"), but the "story" approach usually works great and starts to drag the shareholder into the story ...! -); Also, design the database schema as the best normalized idea you can find to meet all the data layer needs of the user story.
Third, you can sketch layers such as views on top of a diagram; fourth, and optionally triggers and stored procedures that can live in the DB to provide consistency and ease of use for higher levels (but no matter how much DBA nudges you with these questions, don't accept them assurances that they are MUST: they are not - if your storage tier is well designed in terms of normalization and possibly useful views from above, non-storage related functions can always be elsewhere, that's a usability and performance issue , not logical consistency, completeness, correctness).
I think the business level and user experience levels should come after. I understand that this is a controversial position, but I mean that user stories (and the implied business rules that come with them) ALREADY told you a lot about business layers and user layers - so, "nailing" (relatively speaking) - flexibility and "embrace change!" should always be correct ;-) data storage layer is the next order of business, and improvement ("drilling") of higher layers can and should appear after.
source to share
The most important thing to keep in mind is that your first and most likely 2nd 3rd attempt to create a database will be incorrect. This may sound negative, maybe even a bit of a rash (this is certainly more about the "agile" software philosophy), but it's important to keep it in mind.
You still need to do your analysis, of course try to implement one function at a time, but first try to get all the layers working. This way, you don't have to work hard when the specs change and you better understand the problems. You have a lot of data loaded into the system, changing things is getting harder.
The main advantage of this approach is that you quickly know where you are designing, broken, where you have not separated the design layers. One trick I find extremely useful is to do both sqllite and mysql version, so a smooth transition between the two is possible. Since they use a different SQL accent, it highlights where you have too tight coupling between layers.
source to share
If most of the users interact with data, you can design it using the perspective of a form.
-
What forms are required for user input?
-
What forms are required for output reports?
Once you define this, the use of forms will determine that business logic needs to be coded behind the scenes. You take the input, create a set of procedures or methods to fix it, and output what is needed. Once you know the inputs and outputs, you can easily design the required functions.
source to share
The scope of the issue is very wide. You expect me to tell you what to do. I can only say well how to do things. Watch out for using Hibernate / Spring. Since most of your operations look like a db query, hibernation should help. Make sure the tables are sufficiently indexed so your queries can run faster if they are filtered based on index fields. The challenge is to create your own database level, which will be the glue between your application and the db. Build your generic db layer just enough so that it can create queries based on the parameters you pass to it. Then move on to design the higher presentation layer. Developing your application step by step helps as it forces you to separate the db logic from the view logic. When you design the db layer, assumethat not only your presentation layer, but any client can call it. It helps you develop applications that are scalable and adaptable to new requirements. So bottom line: start with DB, integer DB, controller and last view layer.
source to share
For purposes of discussion, I'm going to assume that you are working with a starter application that does not have a pre-existing database. If this is a lie, I would probably change the order of the steps a little.
1 - Understanding the Universe
First, you need to understand what is around you so that you can truly understand the problem you are trying to solve.
- User stories or use cases are often a good starting point. What tasks the user will try to do, and assess how often they are likely to be a good starting point. I like to start with screen layouts and also have a lot of hands on time with users. I believe that having a screen gives our team something really limited to argue with.
- What other tools exist in this area? These days it seems to me that users never use just one tool, they change around a lot. There are two main things you need to know about the other tools you are using:
- (1) - what will they use as part of the process, next to your instrument? Consider direct I / O needs - what might they want to cut / copy / paste from or to? What tools can you suggest for uploading / downloading files in specific formats, what tools they use in conjunction with your tool, with which you might want to share terminology, layout, color coding, icons, or other GUI elements. Focus primarily on the edges of the tools - a real bug I hit on a recent project is emulating the databases of previous tools. It turned out that we had a massive database shift and we would probably better start fresh.
- (2) What (if anything) are you replacing or competing with? Steal good things, dump and improve bad things. Asking users is always better. If you can't at least understand the governance initiative, it is important - is this tool replacing the terrible legacy tool? It may be a legacy, but it may be the One True Feature that has kept the tool in business all this time ...
At this point I find everything is really cloudy - there are some screenshots, some recordings, some schematics or ICDs, but not a very disguised clue.
2 - Logical entities
Or at least what OO books are called.
I don't care what I write on this problem, but I find that any system, I have one true diagram that I draw over and over again. This is usually around 3-10 boxes and hopefully less than the exponentially large number of lines connecting them. W
The sooner you can get this chart, the better.
It doesn't matter to me if it's in UML, a logical database model, something older, or on the back of the napkin (as long as the napkin is wrapped in plastic and hangs where everyone can see it).
The sooner you can get this diagram right, the better.
Once the diagram is done, you can start working on the work, which might be more formal.
I think this is a chicken and egg question about whether you start with your data or start with your screens and business logic. I know you really want to optimize the size and availability of your databases ... but how do you know exactly what your database needs, without screens and interfaces that give you meaning for the data?
In practice, I think this is a cycle that is ever repetitive. You do a little all over the place and then change it all.
Even if you haven't reached a formal agile lifecycle, I find it best to look at design as agile - it will take a lot of repetition and argument before you really feel "right".
source to share
A good start would be to become familiar with layered architecture
Then you create your presentation layer.
At the level of your business logic, implement all the logic
Finally, you implement your data access layer.
source to share
Try to set up a prototype with something more productive than C ++ like Ruby, Python, and maybe even PHP.
When the prototype is working and you see that your data model is fine and your queries are too slow, you can start using C ++.
But since your questions indicate that you have more options, then the data, in which case the speed of langauge's scripting should be sufficient.
source to share