|
Oh, hadn't noticed. Thanks!
"When did ignorance become a point of view" - Dilbert
|
|
|
|
|
Jörgen Andersson wrote: It's BS. It works quite fine. It's just pointless. Multiple schemas is the way to go.
I suspected as much, it was probably a DBA enforcing the schema requirement.
Jörgen Andersson wrote: And then you can search the table with Select * from Foo where lower(bar) = lower('Johnny');
I will need to do some work to understand the relevance on the function based index. However I'm used to SS where case is irrelevant when comparing text, there for the lower() is not required. This will continue to bite me until I get used to it.
My real peeve with Oracle is the all upper case objects, I hate underscores so my names look like FILENAMEDSOMETHING instead of FileNamedSomeThing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: I will need to do some work to understand the relevance on the function based index
Say for example that you have a log table where one of the columns has the date datatype which carries both date and time, and you want to get all occurences from one specific day.
A query for trunc(logdate) would make a full table scan, unless you have an index on trunc(logdate).
Another example, You have a really large table where you have a status column, and the only value you ever make a search on is 'PENDING'. Then an index on "Case When status = 'PENDING' Then 1 Else Null" will be very small and fast, as only those entries where the status is PENDING will be stored in the index as null values are not indexed.
The backside is that function based indexes is costing more to maintain.
"When did ignorance become a point of view" - Dilbert
|
|
|
|
|
Thanks for that Jorgen
While the ability to do these tweaks is very good, the requirement to do them is painful. I beging to understand why a full time DBA is a requirement, I consider this type of tuning beyond the requirements of a developer.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: , the requirement to do them is painful
Having to use Oracle?
Mycroft Holmes wrote: beyond the requirements of a developer
The learning threshold is indeed high, especially if you come from the world of SqlServer.
BTW, I liked your comparison with VB, had it been more catchy I would have stolen it for a sig 
"When did ignorance become a point of view" - Dilbert
|
|
|
|
|
V. wrote: What do I need to watch out for when designing a new database ?
I'm with Mycroft, try to save a dime here and it'll cost a fortune down the road.
V. wrote: but we do have some knowledge about Oracle
I have some knowledge about cars, but that doesn't qualify me to design a new one. People that are taking design-decisions should bring forth rational arguments for their proposals.
I are Troll 
|
|
|
|
|
What's the reasoning behind getting several databases?
If it's getting slow because of large dataamounts you should have a look at partitioning instead.
Get a good DBA for the project to give you proper advice. It'll pay back later.
"When did ignorance become a point of view" - Dilbert
|
|
|
|
|
Jörgen Andersson wrote: What's the reasoning behind getting several databases?
No idea, it blew my mind as well. we still need to go for our first meeting, so if it is up to me this idea will go straight through the window.
V.
|
|
|
|
|
V. wrote: someone opted for multiple smaller databases
sure, why keep things simple when it is so easy to make them complex?
you could as well store each data item in a separate file...
|
|
|
|
|
Luc Pattyn wrote: you could as well store each data item in a separate file...
Of course! That's it. Let's save everything in a nice (bloated) XML file complete with metadata, triggers, constraints, stored procedures, the works ... see how that works 
V.
|
|
|
|
|
V. wrote: nice (bloated) XML
Know a guy who said XML was the next thing for storing data, a year later he deigned he said it.
|
|
|
|
|
I know a company who used xml as the format for etl between major banking systems, stupidest decision they ever made, it worked well with the test system then we introduced them to a production size file.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
V. wrote: What do I need to watch out for when designing a new database ?
Managers.
I've never seen Oracle used that way (though I've seen it done with Rdb), but I'd need more detail. Are you talking multiple databases, but on the same box and disks (spindles)? I don't think you'd gain much.
Can you write SQL statements that cross database boundaries like you can with SQL Server? Can you link servers like you can with SQL Server?
|
|
|
|
|
Add this to your pile ...
Consider how the multiple "smaller" databases are related, do they need to be backed up at the same time to maintain consistency?
How are you going to handle upgrades to these many, small databases ? Do they need to be upgraded at the same time ?
One DB design consideration is to add a qualifier like "ACCOUNT_ID" to the beginning of each primary key, this would let you support many customers in a single database (schema) and still keep the data separate. (This typically applies to a SAAS (software as a Service) configuration. Think of a payroll company with hundreds of clients; each client doesn't have his own database, but each record is identified with a specified ID for the client).
Without knowing any of your details, I would make a list of the current limitations and a wish list of what you would want to achieve ... this should help you in your design.
If you need the advice of a true Oracle expert, contact me privately at david_mujica@yahoo.com and I can put you in touch with a consultant I've used in the past. He is a former Oracle employee with over 20 years of Oracle performance and tuning expertise. Highly recommended.
Good luck with your project. 
|
|
|
|
|
Many thanks for the reply.
To give you an update, this thing is starting out to become a nightmare even before we sat down together. My manager more or less agreed to hire a consultant, but now the dev manager and sys manager seem to want to do it themselves. 
Oh well, in time I can probably tell them: 'told you so' and have a smile. 
V.
|
|
|
|
|
Guys,
I'm relatively new to using databases and have been playing around with SQL Server 2005 to do some stuff. However, I'm looking at extending an application that uses images and documents (mainly pdf) and I want to be able to store these somewhere (ideally in a database). I haven't found any useful information on Google, so wanted to ask others for their suggestions on how to do this. It doesn't have to be on SQL Server and I can basically use any db that's up to the task.
Thoughts welcome,
John.
|
|
|
|
|
jgrogan wrote: haven't found any useful information on Google
Then you are blind, this question is asked at least once a month (if not more often), has been answered with 1000s of excellent articles. Google search works just fine for me[^]. CP article search will give you some excellent articles.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
|
Yup Mycroft,Hiren and Makr already given you some link for best article over how to save image int database.
you can also download the given sample code to learn how to store and retrieve image from SQL server.
Click on the given link to Download
Sample Codes[^]
Hope it will works for you.
|
|
|
|
|
Guys,
Thanks for taking the time to point me at some good articles.
Does anyone have any thoughts on storing documents (pdf, xls, doc) etc in a database and how to do it. The only suggestion I've found is to store them in o/s file structure and use the database to store path and some info.
What would be the pros / cons of using a DB rather than the O/S?
Thanks,
John.
|
|
|
|
|
|
jgrogan wrote: oes anyone have any thoughts on storing documents
Now thats a different question, why not how, much more interesting.
As with anything there are a number of pros and cons, they will depend on your requirements, your hosting environment, the cost of maintenance and infrastructure. Basically 3 styles of storage (using sql server).
1. Files stored in file systems with path in the record.
2. Files stored as binary data in the record
3. Files stored in a database managed file store.
2 means the database may grow dramatically affecting the cost of backup
3 allows you to split the backup to exclude the images (option) reducing backup cost.
Then there is the whole discussion around access of the files, 1 requires file management 2 & 3 require database operation. Having used all 3 I still go for 1 as the most widely used and understood.
Do not take this as definitive, you need to do some research and balance that with your requirements and budget.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Can I assume that the same issues apply to Oracle and mySQL?
What about distributed databases such as Cassandra? Does anyone have any experience of that?
|
|
|
|
|
jgrogan wrote: Can I assume that the same issues apply to Oracle and mySQL?
Absolutely NOT each database will have it's own issues and methods. You are moving into a more esoteric area of data storage and all of them will treat it differently. I only have (relevant) experience with sql server.
Never underestimate the power of human stupidity
RAH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
