I'm the SQL Server developer working with a small team on an appointment scheduling project where the client is insisting on having the business logic and processes reside at the database level. I've tried using functions, stored procedures and triggers to handle the processing, but things aren't working out.
Three different external applications are being used: voice, where calls are taken, agents who enter and request appointment dates and times and a web site where users request an appointment. There are huge timing synchronization issues.
My feeling is that the business processes for scheduling should be developed in a separate module that sits between the database and the external applications.
Looking for advice from anyone who has worked on an appointment scheduling system that involves multiple front end apps and a single back end database. Any help would be much appreciated. Thanks in advance.
I'm the SQL Server developer working with a small team on an
appointment scheduling project where the client is insisting on having
the business logic and processes reside at the database level.
It is unusual for a client to have an opinion about how problems are solved. Normally a client/customer only thinks about the what and the team thinks about the how.
Unless the client is somewhat technical and has a reason why he thinks it should all be done in the database. In this case I would discuss those reasons because they might already be an interpretation of his own problem and is possibly asking the wrong question.
I would create one web application and have the phone operators, agents and web users use the same application (maybe with different rights depending on the role). This way you only have to create one application build with a single code base.
Related
I have been hurting a wall for quite a while now, I am making an application linked to a software that we are using, which will allow the user to either access data from the software with my application and update data with my application on the software.
So here is the whole idea:
So my app will be linked to the software's database (Software Patient) with the help of foreign key (patientId on "App Patient").
And I need to be able to search for email, password, firstName, lastName, secretStuff directly from my app and be able to update data as well on both databases.
The biggest issue here is that I can't make a third table that merge all the data into one because the data from the software's database (Software Patient) will be updated quite a lot directly from the software by others people.
The current stack is composed of :
My application: Node.js with Sequelize, GraphQL & PostgreSQL
Software that we use: SQL Server Express
Thank you in advance!
The app you are developing must get data from your commercial Software Patient (we'll call it SP) system. That presents several questions. You really really need clear answers to these questions to finish designing the data flow in your app. Some of the questions:
How will your app get data from SP? Will you issue SQL queries to SP's database? Does SP publish an Application Programmer Interface (API) for this purpose? Or a data export function you'll use in you app's workflow?
Must your app's view of SP data be up-to-the-minute? Will an hourly update be enough? Daily?
Will your app change SP data, insert new data, or delete data in the SP system? If so see the first question.
Must you reverse-engineer SP, that is, guess how its data is structured, to make your app work? Or can you get specs / documentation from SP's developers?
If you update a reverse-engineered database, dude, be careful!
If your app will use SQL to get data from SP, it will send that SQL to SP's SQL Server Express database. nodejs has tooling for that, but both the tooling and the SQL dialect used in postgreSQL are different. Maybe it would be wise to use SQL Server throughout: doing so reduces the cognitive load on people who will maintain and enhance your app in the future. Neither they nor you will have to keep straight the differences between the two DBMSs.
If you'll use an API, great! That's a clean interface between two systems. (It will probably have some irritating and confusing bugs, so allow some time for that. I've had to send pull requests to several API maintainers.)
If you figure out the answers to these sorts of questions, you'll make a good decision about your question of the third table. It's impossible to address your specific third-table question without some of these questions.
And. Please. Don't forget infosec. You have a duty to keep personal data of the patients you serve away from cybercreeps.
My question is not about a specific code. I am trying to automate a business data governance data flow using a SQL backend. I have put a lot of time searching the internet or reaching out people for the right direction, but unfortunately I have not yet found something promising so I have a lot of hope I would find some people here to save from a big headache.
Assume that we have a flow (semi static/dynamic flow) for our business process. We have different departments owning portions of data. we need to take different actions during the flow such as data entry, data validation, data exportation, approvals, rejections, notes etc and also automatically define deadlines, create reports of overdue tasks and people accountable for them etc.
I guess the data management part would not be extremely difficult, but how to write an application (codes) to run the flow (workflow engine) is where I struggle. Should I use triggers or should I choose to write codes to frequently run queries to push the completed steps to next step, how I can use SQL tables to keep the track of flow etc
If one could give me some hints on this matter, I would be greatly appreciated
I would suggest using the sql server integration services SSIS, you can easily mange the scripts and workflow based on some lookup selections, and also you can schedule SSIS package on timely bases to trigger and do the job.
It's hard task to implement application server on sql server. Also it's will be very vendor depended solution. Best way i think to use sql server as data storage and some application server for business logic over data storage.
I have an ASP.NET Web Application that is connected to a Database that is installed in several clients in production environment.
Some of those clients manage critical information (in other schemas, not accesible for the Web App, like people's money) so the access to execute scripts directly in the database to fix things in my Web App, if it's needed, requires time and also approbation, sometimes it takes weeks..
As some of my clients have a volatile reallity, my Web App has to manage a lot of changes in some short periods of time, that means script executions in the database to alter data or schema, and that means time waste !
Long story short, my question is, is it a good practice to implement a page, only for administrator users, that executes a raw query directly to database?
Think in the scenario where security issue is managed properly.
Something like: Sql Pad where you cannot see the entire database system, just the query and the result as the target database is only one.
No. It's a terrible idea. The security issue is probably not manageable - a web page that's available on the public internet which grants schema modification rights to the logged in user is a horrible security risk. Even if you can't get to another schema, you can easily bring the server to its knees by writing simple SQL which consumers all CPU, memory or disk space.
It's also terrible because you lose any track of what changes were installed in which environment.
If the IT department won't approve your scripts when run from management studio they certainly won't let you loose on your own via a web interface.
I've always solved this problem via automated deployment scripts - execute the schema changes etc. as a part of installing the new version of the web application. That way, you can do things like back up the database before running your changes, keep track of versioning and control access.
We have a setup where we have multiple instances of an application - one instance for each customer.
We call a lot of our reports via URL, passing in parameters on the querystring.
Early on, when we were on 2005, we identified a problem with this: I could change my querystring a bit and get into someone else's data.
We got around the problem by spoofing a user.
Now, due to some intermittent instability in our 2005 report services install, we are taking the opportuntiy to upgrade to 2008. However, the spoofing situation doesn't seem to work any more.
The technet articles that appear relevant seem to say that we need to create a very large security extension (article). This seems like overkill. Surely there is an easier way to call a URL-based report.
How are you accomplishing this in your applications?
Note: This is a repost (paraphrased) of my colleague's question. He didn't get any answers, and since he doesn't have any reputation he couldn't try out the bounty system. I reworded it and decided to give it a whirl. Please be tolerant - we really need an answer to this one. :)
I'm curious, what were you doing in 2005 for user spoofing that doesn't work in 2008?
But to the real question, it sounds to me like you probably should use custom authentication. The sample you linked to actually does a pretty good job of explaining what is going on and guides you through the basics. I had a similar problem to yours where we have many clients accessing reports and it's extremely important that there is no way for one client to get access to another client's data.
I ended up writing a custom authentication extension that creates client specific folders and permissions only the client specific user (which I set via the custom authentication) Browser access to all reports in that folder.
I'd also suggest that you look at http://www.gotreportviewer.com/ if you're writing an application that lives outside of the /Reports/ area. I unfortunately learned that this existed after I'd invested too much time in my custom authentication scheme.
Good luck!
I am developing a framework for various in-house CRUD apps. I've considered several MS technologies (WPF, Access, WinForms, ASP.NET) and have settled on ASP.NET MVC with HTA+Jquery for the client. My reason for doing so is that I need a way to write and deploy quick one-off GUI apps as well as maintaining more robust apps that are expected to have a long life time.
Firstly, I would appreciate some thoughts on the relative merits of using ADODB on the client side versus ADO.NET on the server side. I'm leaning towards ADODB since I'll have client side access to the SQL Server (I've already written a js library that handles interacting with ADODB). However, I can see how developing a RESTful service may eventually be useful.
Secondly, I need to incorporate reporting capability into the system. I can use SQL Server reporting services or crystal reports but the users have grown accustomed to some older applications that use VBA to write reports in Word; so I'm considering using WordML to write the reports.
Thanks.
Database Access
If you need a thin client, then it's probably better to stay away from directly accessing the database from within the client.
The main issue is that you will introduce a high dependency on a specific network architecture and both your ASP.Net application and the HTA will be highly dependent on the database.
Instead I would prefer to sever the dependency on direct line of sight to the DB and have the data to be handled by the server.
This has a few advantages:
for many small changes to the db, you're probably only going to have to update the ASP app.
if you ever need your client app to be functional over the internet (say because some users are going to an outside meeting, need to work from work or your company open a new branch) then you won't have to rewrite your thin client.
you keep better control over access to the resources: only let the ASP app talk to the database and filter what comes in/out of it.
This will saves you having to implement all security on the client: the ASP app becomes the guardian of the database. It's a much better way to secure information and it gives you a lot more control.
Reporting
For reporting I'd use the server again rather than implement complex reporting capabilities in the client itself.
The problem is that you'll always going to get limited on the client if you're using an HTA and don't want to start having to install dependencies on each user's machine.
You'll end-up building a thick client in no time...
If you're using ASP.Net there are plenty of really good reporting tools that will make your life much easier and allow your users to get nice reports in Excel, Word, PDF, etc without you having to code these features yourself.
Crystal Reports is ok, but there are better and simpler alternatives, for example the Developer Express Report engine is pretty easy to use.