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.
Related
In my company we have a selected list of companies that are using our in-house built tool (e.g. Northwind).
When we make changes we deploy these to all our client locations.
The structure currently is: the application is installed at the client's location and the databases sit with them.
However, we would like to consolidate all this information into one database and clients will connect via web services for any data requests.
For example....We have deployed Northwind App and Db to company X, Y and Z and would like to create a single database to maintain all these company's data.
We have reviewed one option which is to create a field for the Company to associate it with the various tables and another option is to create a schema for each company and in this way we can allocate permissions to the relevant company. Is there an alternative to this and what are the pros and cons to the ways we could do this.
One con with adding a company field, is that we have to cater for indexes being the same in all the client databases and this makes it more difficult and the performance of the app as a whole due to multiple requests to the same db. Please Help?
Note: Using Sql Server 2008
Research "multi-tenant database architecture". (For your purposes, think of one tenant as one client.) You'll find a spectrum from "one database per tenant" to "every tenant in every table".
Read carefully. Writers in this field can confuse you. Expect technical terms like shared schema to mean different things to different writers.
See this SO answer for tradeoffs.
For your first step, I wouldn't consider anything besides simply moving those client databases in-house. Just doing that is going to give you and your application programmers enough headaches. You don't need an architectural change on top of it.
That will also give you time for research and testing.
first of all, I don't know if this is the right platform for this question. I hope it is. This is basically an architectural issue or more specifically a database design issue.
My company has asked me to create a service based website where individual subscribers can log in to their own customizable retail store. One fundamental question related to this requirement is designing the database. As I can understand there are two major approaches
Create a separate database based on a template for each subscriber / client.
Have a single database for all clients and link the tables based on primary key fields.
If any one has experience with the above scenario or can provide any useful insights, please do let me know.
Regards
Romi
separate database
You can put them easy to a other dedicated server
You have to administrate 1,000 databases for 1,000 clients
Your application need to figure out which database have to be used
one database with relationships
You have to administrate only one database
Less additional complexity in your application (tons of configurations etc.)
You can easy JOIN tables over all clients. For statistics or what ever.
We are working on an application in CakePHP that will be used by multiple companies. We want to ensure performance, scalability, code manageability and security for our application.
Our current beta version creates a new database for each customer. When a new company joins the site we run a SQL script to create a blank database.
This has the following advantages:
- Better security (companies users are separated from each other)
- We can set the database via the subdomain (IE: monkey.site.com, uses the site_monkey database)
- Single code base.
- Performance for SQL queries is generally quite good as data is split across smaller databases.
Now unfortunately this has many disadvantages
- Manageability: changes to database have to happen across all existing databases
- The SQL script method of creation is clunky and not as reliable as we would like
- We want to allow users to login from the home page (EG. www.site.com) but we cant currently do this as the subdomain determines what database to use.
- We would like a central place to keep metrics/customer usage.
So we are torn/undecided as to what is the best solution to our database structure for our application.
Currently we see three options:
- Keep multiple database design
- Merge all companies into one DB and identify each by a 'companyId'
- Some kind of split model, where certain tables are in a 'core database' and others are in a customer specific database.
Can you guys offer some of your precious advise on how you think we should best do this?
Any feedback / info would be greatly appreciated.
Many thanks,
kSeudo
Just my suggestion:
I think better you keep the customer related data in different databases and authentication related data in a common database So when a user logs in you should have an entry with domain that user belongs to and redirect to that domain and access the corresponding database and data.
Again your concern of changes to the database, You need to implement the changes in each databases separately. I think there is some advantages to this also. Some customers may ask for few changes according to their process. So this can be easily managed if you are keeping separate databases for different customers.
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.
I have a database in MySQL and another database that runs on MS SQL.
The MySQL is the backend database for my website running on Joomla.
I have an ERP running my store. This ERP is made by a 3rd party in .Net
A table called the orders gets updated whenever a user places an order in my website.
The order details must get flushed to my orders table in my ERP.
The table structure in the two databases are totally different so I will do the mapping myself.
My questions are:
How frequently should I transfer the data from my MySQL database to MS SQL?
Someone suggested that I could write a web service that would periodically pump data to my table in the ERP. So I started thinking about Nusoap webservices. Is this the right way or is there a better way to do it ??
I will also have to retrieve inventory-related information from my ERP to my MySQL database.
1: Depends on how often your data is changing, and how often you need to sync up (i.e., depends on your business).
2 & 3: A web service to transfer data could work just fine. But unless you're trying to come up with a general solution, this sounds like a lot more trouble than it's worth.
If I were doing this, I would export the data from Sql Server to a file, then import that file into mysql (mysql my_db < file.sql).
Getting data OUT of sql server in this format isn't so easy (there's no equivalent to mysqldump on Sql Server). But check out this question for some ideas.
If the data itself is compatible between systems (if the columns are equivalent data types), you can overcome the table structure differences by just creating a query in SQL Server which exports the data in the correct order.
In fact, you may be able to create a query who's output is the file.sql for import into mysql. For example, a query such as:
SELECT CONCAT(
'INSERT INTO MYTABLE VALUES (',
myColumn,
',',
myOtherColumn,
');'
) AS SQL_STATEMENT
Produces output something like:
INSERT INTO MYTABLE VALUES (myColumnValue1, myOtherColumnValue1);
INSERT INTO MYTABLE VALUES (myColumnValue2, myOtherColumnValue2);
....
I've exported data from sql server that way on at least one occasion.
How up to date do you need the ms sql database. That is going to be the deciding factor
I don't see any huge advantage to this being a web service.
This isn't a question.
Deciding how often you transfer the order across is a business decision not a technical one. But it is hard to see what competitive advantage you might gain from not processing your customers' orders as soon as possible, so it ought to be a no brainer.
Without knowing a lot more about your infrastructure and architecture we cannot give you definitive advice about approach. I would expect a decently written ERP package to include interfaces for importing and exporting information. Alas such expectations are often confounded. If you do need to write your own interface, avoid web services. Unless you have a very peculiar set-up all WS will mean is that it will take longer to satisfy your customers. I think we have already agreed that is not a good idea.
Considerations for a Syncronization API:
You need to track which new orders
have not been transferred to the ERP
database. A flag is clumsy, a queue
is perhaps more elegant.
Have a job/daemon polling
continuously to identify orders
which need to be transferred and
transfer them in near-real time.
Have a plan for handling the
unavailability of the ERP database.
Construct the mapping in a modular
fashion so you do not have to
rewrite the entire thing just
because of a change to the structure
of one of your tables.
The inventory data will probably
have to be pulled from the MySQL
database, as it seems unlikely that
the third party will allow you to
put code into their database. But
it's worth reading the contract.
Okay based on the replies I got I will rephrase my question giving more details.
I have an eCommerce portal running on Joomla and Virtue mart (never mind what they are !!)
The backend database here is MySQL.
I have an erp written in .net by my friend and the Db used there is MSSQL
Now I am going to host my eCommerce portal.
Following are actions that will take place and questions related to the actions
Action 1:
At the start of the day my friend updates inventory of various products on and erp table
question:
I want the updated inventory from the erp (MS SQL) to get reflected on my website database (MySQL) automatically. How do I do it ?
Action 2:
People come to my site and place orders.These orders are stored in an order table in my website(MYSQL).
Question 2:
I want these update orders related data from my website (MySQL) to be updated on a corresponding table in my erp (MS SQL)
More over the db structures of the tables in my erp and my website are completely different