Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm building a message service for an application. Users are identified by an email address and uid. Uid is also used as the primary key for the user table. I find it faster and simpler to allow my application to see and use that UID than to work with the user's email address.
Does it matter that my application knows something about the database's design ? This is a specific example, but I mean the question as a generalization... how much knowledge is 'too much' when it comes to information sharing between an application and its database ?
I'm asking mostly from the perspective of what would be considered 'good design'. I'm not quite sure how to tag this, suggestions appreciated.
Your application and service layer should abstract your data into a "domain" object used throughout your application(s). Only the data layer, which handles data retrieval and storage, should know the full database design; and it does need to know this information to properly query and store data.
Follow a standard layered approach to your application development - there are many books written on layered architecture.
I think it depends on whether you plan to have this application scale beyond the use of this specific database. I think there comes a point where over-generalization makes the code more complex than it needs to be (and likely less efficient). You need to find a balance, and that will likely depend on the planned future of the application. Obviously, my answer is completely subjective.
It's all depend on how you find your Application needs.
One of good design is Seperate your codes onto layers to make your codes reusable.
Ntier : UI <-- BusinessLogiclayer <--DataAccessLayer.
MVC : Model <--- View <--- Controller.
Something like you can call your domain/DataAccesslayer anytime in your ui because it is just in one class.
Make Sure that your Database is also Normalize/De Normalize and be familiar with it so you should see what is the best approach you needed in your application.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am in the process of designing a database for the first time outside of the classroom in order to make a future java application work with complete desired functionality. As I am trying to design entity relationship diagrams and tables, I find myself always thinking about my java project that is required later. I am beginning to wonder if this is making me more confused and if I am making this more difficult for myself; I am beginning to get nervous that I might not be skilled enough yet to pull this off.
Should I just focus on producing the most normalized database I can and trust that it will allow for my application to do everything it needs to do?
Or,
Should I definitely be keeping my future application in mind with each step of database development to ensure total functionality?
Edit: I would also appreciate any recommendations on free database design tools.
Databases are notoriously hard to refactor, so if you know about something you haven't gotten to yet but are definitely going to do, you need to consider that in your design. This is espcially true if the future something (For example reporting) is going to need to look at lots of records or is going to need moment in time data as opposed to doing calculations on the fly. This is the difference between storing the cost of an order vice calculating it based on current prices for instance. If you just look at the order process, you may thing it is ok to just calculate the price, but reporting will need to know what the price was at the time the order happened or the financial records will be messed up.
You might read this:
What are the general guidelines and best practices to keep in mind while designing database for an application?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've done a lot of research into which architectural database approach is the best, and in the end, I'd prefer the separate database approach. However, most hosting providers are not happy with this (take Azure, with a 150 DB limitation).
My idea now, is to just start with a single database/single schema, use a tenant ID in each column to separate data, and then when it gets too big/slow, look for scaling options.
Is this a bad idea? Should I keep data separated from the start? I feel like security wise it doesn't matter much as long as I verify that the data i'm calling/retrieving belongs to the calling customer.
Also, isn't scaling later on going to be easier with a single big database, as oppposed to having 5000 small databases?
Thanks!
For cloud hosting I think a single multi tenant database is the way to go.
I had the same problem some times ago and opted for one database per tenant since our clients wanted to keep the option of hosting the database on their server. Since we had one code base and many databases on several servers, we had to roll a synchronizing solution to insure that all the schema stayed the same.
We also had some business logic in stored procedures and had to figure a way to distinguish the procedures that had global logic from those that had a logic specific to this database.
it worked but it was awkward and I wish we could have used a single database
Anyway, like said before each way has pluses and minuses, you just have to decide what is the most important to you and work around the minuses
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am developing with Delphi XE2.
I am planning a software for primary and secondary school. This school have 1,500 students. The database model is relational and we plan to keep the whole history of each student as the years move on. (well at some point it will be archived, but mostly all the relationships will be maintained for a good time)
I used to write Delphi apps using DBISAM V4 from Elevate Software. I hold a licence of it, so it is still a possibility for use it.
However I had contact with many companies using Firebird recently, some using Postgres and many websites with MySQL.
I don`t see a need to go paid databases, since this type of customer is sensitive in investment. So any database that is free for such use, plus the option of keep using DBISAM. I like it but it is getting old.
I prefer to put the business logic on the software, not in the database, so no need to intricate logic or procedures on the database side.
My questions is: What I need to consider to choose the correct database?
This Wiki post can help you. Besides that, you have to decide for using OLE-DB, ODBC or DBX as middleware technology. Depending on which one you will find or not support for Delphi.
Another criteria include know-how on the database options and rectrictions/requirements on security and scalability.
However, no matter what DBMS you choose, my best advice for you is to isolate the access to it in a dedicated service layer so most of your application won't be directly dependent of it.
In your place I would model the application in terms of domain classes and would invest in a persistence layer. If you have to go for another DBMS in the future, most of you code will be preserved.
DBISAM will work here, and you can even write a webservice in Delphi, to provide access to tablets and such. You need to start thinking about the things that really matter here, such as what platform the users are on, how many users total, how many users will be using the database simultaneously (average and peak), how many rows are kept per student, how many add/delete/updated rows daily, etc.. DBISAM has limited SQL. It does a lot, but not everything that you can do in other databases. Their newer product, ElevateDB, addresses most shortfalls, including Unicode.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I understand that "lines of code" may be not a fully accurate measurement standard because a lot of Salesforce configuration might be done through a gui. Nevertheless, for the sake of argument, let's say that either each config field manually filled out in the gui is like a line of code, or else let's imagine the configuration being done entirely in source code, if Force platforms allows it.
Well, so, how big would a typical "professional" or "enterprise" level Salesforce installation code base be? Is it like 1K lines? 10K lines? Are there many 100K and more cases out there?
You will hardly get a meaningful answer. Just as an example, one of my clients is an ISP, we've been at their enterprise instance for 5 years now and we have a code base of about 600KB (+testing code to satisfy 75% requirement) with more than 100 classes and even more pages, about 20 custom tabs, 30 custom objects and appx 150 custom fields on factory objects, all that complemented by a ton of work done on administrative customization. In contrast, their sister company operating the same business in another territory has its own instance without a single line of code, but they use it just for opportunity tracking and do their provisioning, operations, case mgmt and other stuff from different (legacy) systems.
The overall average statistics is something that salesforce only knows and they don't seem to be sharing that info. Either way you should get a trial of whatever instance you want and see what is missing in terms of your business requirements and plan accordingly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Do you think it is alright from architectural stand-point to have ViewModel - View without Model for temporary things?
E.g.: I want users to input some paths so I can open some files later on. It doesn't make sense for me to store the paths anywhere just ViewModel and when the user clicks "Show all files" I then construct models of the files and ViewModels for View that represent them somehow.
So really my only model is the model of the file.
I think sometimes people mistake design and architectural patterns as hard and fast rules. We need to understand that these are just guidelines. One example of this could be the way different programming languages implement singleton pattern.
So I would say if you need the functionality of View Model to be bound to View but really don't require a model, there shouldn't be any problem in ignoring the model. I would suggest use these patterns as guidelines and not as hard and fast rules. Feel free to make minor adjustments wherever applicable.
But at the same time keep in mind that you are not violating the purpose with which these layers are created. It should not happen like we bypass the model and start querying the backend database directly from the View Model. As long as the basic principle of separation of concerns is adhered to everything should be fine.
Of course. If it suits your business process, why not.
But you could probably still use a model to have some sort of in-memory persistence of the entered paths.
Sure. There's no sense in moving the file-opening logic to a separate object just so that you can say you've done it.