I am tasked with creating a reporting application working off a internal database.
The database is populated by some other tools, and the aim of the application is basically to read from the DB, and display some charts.
To that end, the application will only ever connect with a read-only account.
I have been reading about ORM, especially Entity Framework, but is seems to be very focused of making DB structure, and DB updating easier.
Since the only purpose of the app is reading from the DB, will I gain anything from using an ORM such as Entity Framework or Linq2SQL, or should I stick with good-ol' SqlCommands?
If you need some kind of dashboard to display aggregated data from a SQL Server database I would recommend Reporting Services. You would need a SQL Server license on the machine that serves the site.
You can of course create a dashboard from scratch using Entity Framework, but hey, why reinvent the wheel?
Related
I am currently working on a new Web Application. I really love the idea behind firebase (augularfire) for the realtime data sync. But I can't figure out how to organize all the data, make each customer (enterprise) have his own data, and ensure no data is shared between each enterprise.
In a regular MySql server, I can create a database per enterprise (best implementation for speed and security) or simply add a table Enterprise and a table Customer with enterprise_id. Which is the best approach in a Firebase DB?
I'm currently working on an Intranet application project, using ASP.NET MVC 3.
One of the primary requirements is that all data created with the application must be available in the clients' ERP software as well; they work with MS Dynamics NAV. Accessing the data is not really a problem, as NAV uses SQL-Server as its database.
In fact I already have a working prototype, that uses Entity Framework for data access. The main issue here is that my company also develops quite a lot of custom functionality within the ERP, and thus some of the database tables I have to read from and write to often change. This would not really be a problem in a usual situation, but here, each and every field in the database is marked as not null, a very annoying feature of Dynamics NAV. That means that every field added to a table breaks my code, as Entity Framework tries to insert null when it doesn't know of a field.
Can any of you think of a solution that would not require regenerating the model after each change in the tables ?
Edit : Unfortunately our client still uses version 4.0 of Nav, so webservices are not an option.. I have already developed another application for them (part of a Warehouse management system which runs on mobile terminals), accessing SQL Server directly, but it was not quite the same scale.
If your requirement is to integrate with ERP like Dynamics NAV you should pass all data access through its application server. I think Dynamics NAV expose web services for communication with application server. Accessing its tables directly is way to disaster especially due to transactions and possible deadlocks. EF will make this even worse because you will not be able to tweak queries.
Application integration through database requires full control over SQL generated by all accessing applications.
The answer to your main question is no. The point of database first development is to regenerate your model after each database modification - especially if each database modification is breaking change (another reason why integration through database is not a good choice for you).
My company is planning to turn an older Winforms application into a WPF/Silverlight Client/Server app.
The idea of having a small server app is to have a list of the accessible data bases combined with the user type that may access each of the databases, instead of having to manage databases in each client's admin control. Additionally, it would be great if the SQL request would be handled by the server which would then return the result.
The app is supposed to work on a arbitrary set of databases which will be "registered" with the server and users get a list of databases according to their authentication rights. They can then do practically everything on those databases what one can imagine. The system should be able to handle up to 2 million rows.
The databases are very different, there can be many of them, they can be MS Access, Oracle, SQL Server etc., so no way for me to specify them all before. On top of that, communication with a SQLite cache is needed.
I already have everything I need for the SQL queries from the Winforms app.
I was thinking:
1) A simple WCF server specifying in a config file the available databases per user type.
2) Interface that specifies all necessary SQL queries that can be made to the server.
3) Client...
The idea is:
a client-server application, where the client uses WCF services to execute SQL queries (INSERT, UPDATE, SELECT, etc.) on tables by invoking services methods.
The service should ideally be consumable for both the WPF and the Silverlight app.
Is that the way to go? Which exisiting technologies might I want to make use of regarding formats, communication, services etc.
If that is problematic, I would consider going back to a desktop app, but then how to ease the user type/database access problem for each client?
I would stick with ADO.NET and start with the DbProviderFactory class. This will let you determine the proper database access based on information supplied by the provider using the Factory Design Pattern. So instead of having to create a specialized objects for each database type and database, you can abstract that logic with the DbProviderFactory.
Here's a link that shows some examples: http://msdn.microsoft.com/en-us/library/wda6c36e(v=VS.100).aspx
I'm going to develop a Web Application with two essential requirements:
Total independence of DBMS. The application should work with different DBMS like Oracle, SQL Server and MySQL. That is, Client 1 use this application with SQL Server, but he wants to migrate to an MySQL Database. The application should be able to work with this new DBMS without needing to make changes to the application code. The only change I want to do is to change the connection string.
Scalability. ie, we will have a clustered SQL Server installation.
I know that Data Access Block is able to handle different DBMS and I assume it won`t be an issue to meet the scalability requirement, but I don't know if this is the case with Entity Framework.
Choose Entity Framework, for a couple of reasons.
First, EF is where Microsoft is putting all its data access emphasis for the foreseeable future. Entlib's data block is primarily there to support folks already using it.
Second, Entlib will give you a regular API, but it doesn't insulate you from the differences in SQL statements. Oracle in particular does stuff with cursors no other database does (or needs to); EF at least attempts to give you a uniform API.
As far as scalability, that's all about the design of your database and application, no data access tool will give you that.
Our IT manager is asking my help on deciding on which would be the best to save the data. Is it in sharepoint or sql server.
On my side I don't know much about saving data on sharepoint server, how does it work, how fast, how secured, etc. I even have a doubt if sharepoint is capable of complex database design. As far as I know, sharepoint is not a database server that's why I have this doubts.
So obviously I would say Sql Server would be my prefered storage and also because Sql server is known to me for a long time already. Considering my 3 weeks exposure on sharepoint vs. 7 years on Sql Server. I don't have the enough experience to witness the strength of Sharepoint for me to decide on what to do. So to be fair on sharepoint I would like to ask you guys out there who are more experienced on this.
My questions:
1.) Does sharepoint have the ability to store data?
2.) If sharepoint can store data, what are the pros and cons?
3.) Can it cover a complex design such as relational database design like sql server does?
4.) If you where to develop a sharepoint project, would you choose sql server as the backend?
Thanks in advance!
It obviously depends on the application, and complexity of it, who the client or audience is, and how you want to deploy it.
Here are my answers to your questions:
1. Yes
2. Pros:
It provides a UI for updating data.
Cons:
Creating relational structures will be complicated.
Think custom lookup lists, associated with other custom lists.
3. Yes, but I wouldn't try it.
4. SQL Server, but this depends on the project and
isn't an entirely technical decision.
Personally, I think given your skillset, you should use SQL Server, if your manager has said it's up to you.
SharePoint itself is built on top SQL Server and ASP.NET.
Yes. You can create a custom list (basically similar to table structure), you can store document along with its metadata. You can store web pages if you are using it as your publishing (CMS) platform.
It's not supposed be a relational engine like SQL Server. Pro: versioning, workflow, for most cases, UI is there to support data input / editing. Con: Limitation of the UI w/ large amount of data.
To some degree you can relate one list to another field in a different list / document metadata.
See what I said before point 1.
SharePoint offers its own database layer built on top of SQL Server.
A complex object model is provided, and the SQL language API not available.
Acsess is by API, REST, and UI List Webparts with views; NOT SQL and the database is not accessible except through interfaces.
Deep inside data stored in Entity-Attribute-Value triples (specifically: site, web, list, item, state, field, value) such that each value goes into its own record. This is strickly non-tablular.
Maintains a dynamic end-user populated Metadata dictionary.
As a non-relational layer above a DB is offers inheritance, multi-type list, hierarchies, taxonomies, versioning, check in/out and other advanced features missing from a relational model.
Documents may be attached to a list.
Extensive use of GUIDS for identifiers, but this causes problems when moving partial related data between systems.
No referential integrity.
No joining of database tables or lists.
Filtering is more limited than in SQL.
No concept of a schema.
Parts of SharePoint break when restoring from a backup or when published to a separate site.
Rolling new features and data from development to production is problematic and sometimes breaks.
Hope this helps.
Sharepoint is obviously not a Database Server but somehow it works on some ways.
1.)Yes
2.)You can but not as complicated as Sql Server does.
Pros: It's the interfaces the gives sharepoint the edge, UI grants the user a friendlier way of inputting data.
Cons:Just like what I've said complicated database design is not easy to do.
3.) 100% Yes
4.) I would prefer Sharepoint if the application doesn't need complex design on data. Definitely Sql Server for enterprise type of application.