Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!in.100proofnews.com!in.100proofnews.com!fu-berlin.de!uni-berlin.de!207.140.171.60!not-for-mail From: Chuck Newsgroups: comp.databases.oracle.server Subject: Re: 2 Oracle doubts Date: 8 Aug 2003 15:41:41 GMT Lines: 43 Message-ID: References: <42d54ae4.0307250016.679a412b@posting.google.com> <3f33b482$0$83915$45beb828@newscene.com> NNTP-Posting-Host: 207.140.171.60 X-Trace: news.uni-berlin.de 1060357301 30162635 207.140.171.60 (16 [85580]) User-Agent: Xnews/5.04.25 Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:240107 gters@zdas.com (Gters) wrote in news:3f33b482$0$83915$45beb828@newscene.com: > In article , Quarkman > wrote: >>On 25 Jul 2003 01:16:17 -0700, delavega >>wrote: >> >>> Hi. I´m a MySql programmer, but i need make a application with >>> Oracle 8.1 Server. I have 2 doubts (for the moment) >>> >>> 1-Can i have a Oracle table without primary Key? >> >>Yes. But this is a *relational* database, so why you'd actually want >>this I can't really imagine (OK, I've seen heaps of bad applications >>who wouldn't know a primary key from a prune, but they're really *bad* >>apps.) >> >>> 2-In a sql, the date fields are with quotas ("")? Exists the >>> direct comparation between dates (<, >)? >> >>Get thyself to tahiti.oracle.com and start reading the documentation >>on issues like this. Short answer: dates need a fair bit of >>manipulation, but yes you can do maths with them. >> >>~QM >> > alot of packaged apps do not have any keys on thier oracle tables, > they do it all interanally. usually it is to hinder reverse > engineering of their apps, having all the relational stuff in the > tables gives insight into design. I have seen the internal tables of > a very well known and expensive enterprise package. no keys, tables > and columns have almost nonsense names (and in a language other than > english) > I pity the poor sap that has to manage that database ;-) I think a lot of apps are writeen this way not to prevent reverse engineering, but because they are written to run on every RDBMS imaginable. To minimize customization for each RDBMS, they bury as much as they can in the app. Not to mention the programmers probably have little specific knoweledge about individual RDBMS's.