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.
Related
Yes, I am a learning Access and am not familiar with Joomla!, but I am working on creating an Access database (in Access 2013) so multiple users can have a user friendly way to look at and edit our data via forms, use the queries, etc. We are trying to transfer our Schedule worksheet from Excel to Access.
1) My co-worker is working on Joomla! version 3.6.2, and I would like to know if Joomla! has forms and the ability to do queries, etc., like Access, so we can use Joomla! on the front end and house our tables in SQL server on the back end?
2) I don't know if Joomla! is compatible with SQL server, but do you recommend us sticking with Access as our database or using Joomla! on the front end? We have other things in Joomla! and would like to see if we can view and make changes to our Schedule via forms and queries, etc. in Joomla!, making it the one place to go to for all of our needs.
Thank you for your help.
Microsoft Access is a good tool for learning what a relational database is but I suspect there are less limitations with SQL (or MySQL) in terms of the amount of records, the size of the database and with sharing the data with multiple users.
There are quite a few forms extensions that enable you to not only submit data to the database but to also retrieve it in whatever way you wish (sometimes with a little custom coding).
Joomla supports SQL but MySQL is probably the preferred database.
I have a client/server application currently that has a Oracle 10G database. The company that I purchased the application form is not providing support. The company when I purchased the application provided me a SQL tool with a READ Only access access to approx 30-40 views.
Based on my analysis the views provide some but not all the data and I want access to data which may be in other tables
I am not a developer but the business owner so excuse my naivety in some of the questions below.
Can I export/duplicate/replicate the Oracle DB to another Oracle DB and will a Oracle DBA be able to view/access all the tables and understand the relationships
What is the best way to create a duplicate DB that keeps in sync with the application DB which we currently have. We would like to use the Duplicate DB as a backend for a website.
Thanks a lot!
ML
Assuming that the Oracle database resides on a server in your organization, it seems premature to be talking about talking about replicating the data to a different database. It is certainly possible to do so. But you can also run many, many different applications against the same database. Unless you know that the current database server would not be able to cope with the additional workload of the new application or you are planning on investing the time and effort to transform the data into better data model as part of replicating the data (which is extremely unlikely if you don't already know what the underlying data model is and if you don't already know that this data model isn't going to work well for the new application), you probably want to start with the assumption that you can probably build the new application against the existing database.
A database developer or a DBA should be able (again, assuming that you own the server) to determine what underlying tables exist. That person should be able to at least get some idea of how the tables relate to each other based on the existing view definitions. If the original company did a good job building the database, a new developer/ DBA should have a relatively easy time understanding the relationships. If the original company did shoddy work or was intentionally secretive, it will be a more challenging undertaking.
I would like to fill in a Microsoft Word document using a SQL Server database, preferably without doing the document processing on the server side.
From what I read, Microsoft does not recommend server side word processing as it was not designed to be scalable, the UI will come up and there would be no one to click it, and licensing issues.
Therefore I would be interested in a way that a client could type up a Word document and then put something like Name: <!name> and then connect somehow through a web service to receive a record set or something that will fill in all the tags with the information from the database.
How would I go about doing this? If this is not possible, is there any way a client can design the form they want to use, and have our program fill in the template fields?
If Word cannot do it, can Open Office?
Thank you.
With OpenOffice, this is at least as hard as with Microsoft Office. Unless you are more experienced with OpenOffice development than with Microsoft Office. I find it very hard to gather technical documentation on OpenOffice customization development, while Microsoft does it best to attract developers.
If you like to pre-fill a Word document with data from SQL Server or for instance Teradata on a PC using Microsoft Office, I can recommend you Invantive Composition for filling Word documents from the database (please note that I've been involved with that product). You can extend it further using C#, but out-of-the-box it is already able to connect to various database platforms through a webservice. I think it can also connect directly to SQL databases, but that requires maintenance on local database drivers.
Please note that Invantive Composition is preliminary aimed at non-developers; a financial or legal employee with high school or university must be able to create templates for the rest of their collegeaus. Of course, IT and security department still need to make sure only the data that should be available on a need-to-know-basis is made available. That can be done on the central webservice or using a separate database or separate database views.
Can I store any custom tables in SharePoint's own database?
Is this supported behavior or not?
(I mean tables in MS SQL database, not SharePoint lists.)
If I can, how well does this play with backup/restore functionality?
What are possible caveats?
For anyone wondering why I'm asking: there's an app which is bound to SharePoint server and needs to store some purely relational internal information that doesn't make sense apart from that SharePoint instance. I would like to narrow down data storage to one place but I'm not sure if SharePoint likes its database being used for other purposes.
I'm using SharePoint 2007.
Is it possible? Sure. Should you? Nope.
The SharePoint content/configuration databases are subject to change with any update Microsoft releases, and any changes you make will very likely be destroyed, and if your farm depends on them, be left non-functional.
If you want to store purely relational data in a set of tables, just create another database. There's nothing stopping you from using the same SQL Server instance that houses your SharePoint content and/or configuration databases to store other relational databases as well.
Not a good idea: Support for changes to the databases used by Windows Sharepoint Services
...
Making any modification to the database schema
Adding tables to any of the databases
...
If an unsupported database modification is discovered during a support call, the customer must perform one of the following procedures at a minimum:
Perform a database restoration from the last known good backup that did not include the database modifications
Roll back all the database modifications
It is even worse than the above. It is likely that future upgrades will notice your changes to the content database schema and refuse to upgrade the database period.
Our client wants to support both SQL Server and Oracle in the next project. Our experience comes from .NET/SQL Server platform. We will hire an Oracle developer, but our concern is with the DataAccess code. Will NHibernate make the DB Engine transparent for us? I don't think so, but i would like to hear from developers who have faced similar situations.
I know this question is a little vague, because i don't have Oracle experience, so i don't know what issues we will find.
You can easily use NHibernate to make your application database-agnostic by following some basic practices:
Design your object model first.
Do not use any database-specific code. You need somebody with good C# experience, not an Oracle developer. Do not rely on stuff like triggers, stored procedures, etc.
Let NHibernate generate the DB schemas at least initially (you can tweak things like indexes later) It will choose the best available datatypes for each DB.
Use a DB-agnostic POID generator (hilo or guid) instead of sequences or identity.
Try to avoid using SQL. HQL and Linq work fine in 99% of the cases.
Avoid NH features that are not supported by all of your target DB (for example, Future, MultiCriteria, etc)
NHibernate has a great community. You can always ask your questions in http://groups.google.com/group/nhusers besides posting here.
There are three things to consider - the ISession object, the SQL queries that are generated and your plain-old-clr-objects that are mapped to tables.
NHiberante will generate the required SQL queries based upon the chosen database dialect. If you configure NHibernate to use the SQL Server dialect it will generate SQL server correct SQL statements. This can easily be configured dynamically at runtime based on configuration.
You also need to configure your session to connect to the right type of database. Again, various configuration methods can support dynamic ISession creation at runtime.
Your actual data objects which are mapped to tables should not need to change based on database choice. One of NHibernates strengths is flexibility it provides in supporting multiple databases via a (fairly) simply configuration change and some up-front architectural thought.
See http://codebetter.com/blogs/karlseguin/archive/2009/03/30/using-nhibernate-with-multiple-databases.aspx for some examples of how you might abstract the underlying database away from the creation and usage of NHibernate.