Database design
-
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
-
It's point 9 that's the killer. We have some data that comes in as x,y coords and we want our materialised views to be spatial, so you get screwed up when you try to construct a location sdo geometry.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Spatial is totally out of my line of work, but I would have thought point one or ten would have been the real killer. I'm curious, what would have been the purpose of the mv if it had been possible?
"When did ignorance become a point of view" - Dilbert
-
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
-
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
-
Spatial is totally out of my line of work, but I would have thought point one or ten would have been the real killer. I'm curious, what would have been the purpose of the mv if it had been possible?
"When did ignorance become a point of view" - Dilbert
We are reliant on a separate supplier for a standardised gazetteer implementation in one particular project (the data's provided by the government), but we need it in a different format (a spatial one for spatial searches). We need the view to be updated on import of data into the master gazetteer. We've worked around the issue, but it would be nice not to have to work around the issue.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
Pete O'Hanlon wrote:
Nice. I didn't know you could do that. A 5 just for that trick.
That single trick alone is worth the extra trouble of using Oracle
"When did ignorance become a point of view" - Dilbert
I've balanced out the univote.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
I've balanced out the univote.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Oh, hadn't noticed. Thanks!
"When did ignorance become a point of view" - Dilbert
-
Guys, In a few days I have a meeting internally about redesigning the Oracle database from scratch. The downside is that none of the meeting participants is a real DBA (IMHO we should hire a DBA consultant for advice), but we do have some knowledge about Oracle. one of my major concerns is that someone opted for multiple smaller databases (that should communicate if necessary) I can think of multiple reasons why this is a bad idea, but I couldn't find any satisfactory links to proove it. (Maybe it isn't that bad after all?) I did write some stuff down already (never delete, but rather 'inactivate', use history mechanism etc..) In short: What do I need to watch out for when designing a new database ? If it can help, we're an insurance company, but we also do call taking (could result in some tables having rapid changes when a lot of calls come in) Also we will start with adding one project to it, then a second, a third etc... so no one time porting to another database. Many thanks in advance.
V.
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. :thumbsup:
-
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. :thumbsup:
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. :sigh: Oh well, in time I can probably tell them: 'told you so' and have a smile. :-\
V.
-
We are reliant on a separate supplier for a standardised gazetteer implementation in one particular project (the data's provided by the government), but we need it in a different format (a spatial one for spatial searches). We need the view to be updated on import of data into the master gazetteer. We've worked around the issue, but it would be nice not to have to work around the issue.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
I've been thinking about this one for a while. If I understand you correctly (and it's quite possible I don't), you're getting XY coords from an external source that you load into a table, and you want them transformed into a sdo_geometry datatype which you do via a materialized view. And for some reason you can't do this at the import. One possible solution is to add a virtual column into the master gazetteer that calculates the sdo_geometry. From 11g you can index, gather statistics and partition by a virtual column, which makes them a lot faster and quite useful nowadays. There are probably other limitations that makes it impossible to drop the view, but nothing I could find on a quick google.
"When did ignorance become a point of view" - Dilbert