I was wondering if there is a common industry interface that normally is used when creating the database interface for an end user? In years past I used to see a lot of FoxPro front ends on databases, but now as expected web interfaces seem to be more common. Just wanted some input on what real world DBA folks who deal with this on a daily basis see.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Learning SQL, curious about user interface options 2
- Thread starter atascoman
- Start date
-
1
- #2
Olaf Doschke
Programmer
Funny that you mention Foxpro. I still support and upgrade several foxpro applications. An end is still not in sight, but we migrated data from DBC/DBFs to MS SQL Server. I wouldn't recommend starting a new Foxpro application, though.
Additional to that we use XCASE for database modeling, which as far as I know is written in Foxpro, at least it uses DBFs to store meta data about the database models.
From the DBA perspective: VS coming with SQL Server has some project types for Analyses Services, Integtration Services and Reporting Services and the rest is SQL Server Management Studio. And this is totally sufficient to learn SQL Server and T-SQL.
Besides XCASE those tools are also sufficient for my needs as application developer.
I've been recommended the Redgate SQL Toolbelt as anther third party add on for DBA tasks, but that's beyond the scope of my needs for database deployment.
If you're rather asking for frontend application development with an SQL Server backend then surely .NET (C# und VB.NET) and Java are the two main candidates to make use of the backend for application end users. This kind of end user is not at all database aware, especially with an SQL Server backend. Neither if it's a small Express edition installed together with the software, nor if it's big company Enterprise Server, for which one or more DBAs look after the data.
For those end users GUI, reports and workflow count much more then how the data is persisted. You often end up with a variety of end points, be it Web- or Intranet Apps, Desktop Apps, Office or Sharepoint and Mobile Devices. That's the advanatage of a database server, you have the data encapsualted at a central point and can share it for the different types of end users and their different needs.
Bye, Olaf.
Additional to that we use XCASE for database modeling, which as far as I know is written in Foxpro, at least it uses DBFs to store meta data about the database models.
From the DBA perspective: VS coming with SQL Server has some project types for Analyses Services, Integtration Services and Reporting Services and the rest is SQL Server Management Studio. And this is totally sufficient to learn SQL Server and T-SQL.
Besides XCASE those tools are also sufficient for my needs as application developer.
I've been recommended the Redgate SQL Toolbelt as anther third party add on for DBA tasks, but that's beyond the scope of my needs for database deployment.
If you're rather asking for frontend application development with an SQL Server backend then surely .NET (C# und VB.NET) and Java are the two main candidates to make use of the backend for application end users. This kind of end user is not at all database aware, especially with an SQL Server backend. Neither if it's a small Express edition installed together with the software, nor if it's big company Enterprise Server, for which one or more DBAs look after the data.
For those end users GUI, reports and workflow count much more then how the data is persisted. You often end up with a variety of end points, be it Web- or Intranet Apps, Desktop Apps, Office or Sharepoint and Mobile Devices. That's the advanatage of a database server, you have the data encapsualted at a central point and can share it for the different types of end users and their different needs.
Bye, Olaf.
- Thread starter
- #3
-
1
- #4
I would say a web application is the most commen interface for the end user these days, due to the centralized installation of the application on server(s) (i.e. each user doesn't need to install a "front end").
An end user would typically never have direct access to the raw data through tools such as SQL Server Management Studio since they probably don't know SQL syntax or the business rules of the application.
A typical architecture would be:
GUI - the stuff on the screen
Business Logic - all the rules for using the application (example: doesn't allow entering a Date Of Birth that would make someone 200 years old)
Data Layer - code that connects the Business Logic to the Database
Database - the actual database
When designed correctly, each of these layers can be deployed on the same or different servers.
There are a number of skills that should be mastered before writing a web application, for example how to avoid SQL Injection attacks.
An end user would typically never have direct access to the raw data through tools such as SQL Server Management Studio since they probably don't know SQL syntax or the business rules of the application.
A typical architecture would be:
GUI - the stuff on the screen
Business Logic - all the rules for using the application (example: doesn't allow entering a Date Of Birth that would make someone 200 years old)
Data Layer - code that connects the Business Logic to the Database
Database - the actual database
When designed correctly, each of these layers can be deployed on the same or different servers.
There are a number of skills that should be mastered before writing a web application, for example how to avoid SQL Injection attacks.
- Thread starter
- #5
- Status
Similar threads
- Locked
- Question
- Locked
- Question
