Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What's the diference between using relational database and relational database-object(hybrid).
Im making an application of adverts. Using common relational database, i think I could make tables of each type of adverts: cars,technology,estates,employment, services, this is the way a I do it.But reading about relational database-object I found that you can create a type field in the database(Oracle) that allows you to encapsulate another fields and methods, so what if I make only a table of adverts, knowing that all adverts have fields in common like title, description,the date it publish, images, but I can add a field that encapsulate another objects that will be cars,technology, employment, and inside of each one encapsulate attributes to them like
cars(model,brand,price),
technology(state,price,accesories,dimensions)
emloyment(job,payment)
Well this is the idea, actually for every advert you can actually enlarged the functionality, making a database for each one.
My question is: what are the potencial problems using relational database-object?
What is the best option?
Most if not all, of the worst database designs of the last ten years have at their root tables built to an object model rather than fitted to a relational model.
OOP is a programming thang; its concept of combining behaviour and data together works well when building APIs, etc. But it sucks when it comes to persistence, leading to horribly large tables, lots of duplicated data and monstrously slow queries. I'm not saying that's inevitable but it is the way to bet.
So why does Oracle support Types in the database? Because there are advantages to defining complex data types with behaviour: XMLType is one such, and Oracle Spatial makes extensive use of objects. But these usages are limited to individual columns of regular relational tables. The intention is not, and never has been, that we use object tables to store all the data in the database.
By all means use Types in your Pl/SQL programming. I have done this extensively, and for the right use case they can be extremely effective. Just don't store your data in them.
The most significant difference is that Oracle's object-relational technology is rarely used.
Very few programmers or DBAs have significant experience with object-relational technology. Database tools do not support objects well, or at all. Oracle does not support the technology well - it's buggy and does not get updated frequently.
Of course, just because a feature is rare does not mean you should ignore it. There are cases where Oracle's object-relational features work very well. But if you're planing to build a significant part of your database using objects, you need to consider the loss of skills, technology, and support.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am old school and new to MVC. I like the MVC that's more focus on action. But MS has bundled it w/ EF together, it's hard to not to use EF nowadays.
This is what I thought:
1 - RDBMS stored proc/package suppose have better performance over LINQ. For instance, SQL Server Transact-SQL supports paging now, compared with LINQ, TSQL definitely has better performance. So LINQ is only good for people don't know TSQL or PL/SQL in terms of performance.
2 - I've tried using LINQ w/ stored proc. Thought it works but has many limitation, for instance, .dbml files are strongly-typed, it prohibited any attempts of re-formatting the data, such as adding an anchor to a field of display. Well, one might say you're not supposed to do so. Let me give an example, business wants to make a column clickable in a grid. There are a number of ways to implement, one of the quickest is to embed an anchorto the column returned from a stored proc, very little change on the UI. Hence QA just needs to test a few. But using EF as the foundation, anything based on this model/class must QA again.
3 - Model-first or Code-first wouldn't get a nice normalized large-scale database implementation, this is because if a developer doesn't know TSQL he wouldn't be good at RDBMS design.
4 - This is the most important issue: in an enterprise environment, we developers can NOT dictate schema and table definitions. Even with DB-first approach, sometimes we don't even know where it comes from. But that's what EF is good about, right? You might say. Imagine EF detects all schema and what returned from stored proc, then builds all data-layer/class for me. Great, but there is a need for a real-time median price which is not in the database at all, we add it in w/ some customization code. It will be gone if another scan and detect is needed because our client requests something causes a tiny change in the database. How do we avoid this hassle of losing customization code?
5 - Sometimes we need to run "update-database" command in the package console so EF can work. It's almost impossible to explain to Operation and DBA that they are harmless during release.
However, as EF is getting popular there must be a new-school way to make it work. Can some experts educate old-school please?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am using redmine for project management and issue tracking.
I was looking at the database tables and the underlying structure and was wondering if anyone who is VERY experienced with database architecture can comment on the structure.
I am concerned that once there are many users and hundreds (or thousands) of projects (each project containing many issues, with each issue containing many messages, etc.), the database structure could possibly turn out to be a weak point.
How is the performance impacted by this design?
I would like to hear about the Pros/cons of how the tables are laid
out and how the data is separated or normalized, and whether or not
it might be worth re-structuring.
What would be the benefits of
separating the data out to more tables (with less columns per table)
The database structure looks typical for an issue/project tracking system. If you can come up with a better structure, I would be very interested in seeing it :).
What you have to remember is that applying normalisation rules are all fine and dandy but if you apply it too much then sometimes you may hit performance problems (and the dreaded de-normalisation hacks start to creep in). In other words, there's a balancing act to be done between some normalisation and hardcore (too much) normalisation.
You would have to have a good reason to re-structure that database model. For example, it could be that for some particular query the database design does not serve the answer in an efficient manner. You could then start asking yourself what other table(s) could be created that would hold the data that I need in an efficient manner for optimal query performance. Also you could ask yourself what other indexes could be in place which will allow for optimal performance.
The fact is that until you have the very high number of users and projects and issues in this database as you predict it is hard to answer those questions. Maybe you could generate the data for some fake users and projects and test out the database to backup your concerns? Remember the adage of Professor Donald Knuth: Premature optimization is the root of all evil.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I find myself very frequently taking the decision between storing a object in the data store more appropriate to its nature (Events, Documents, Graph, etc) or just sticking to the relational database and moving on with my life, and i bet some of you do too.
I'd like to know what criteria you use to take this decision, for example, when is using NoSQL with little data is "premature optmization" and when it is "good enginneering"...
So, When to use the best data store and when to stick to relational?
I see a lot of questions with the nosql tag that include the following:
They want to mix RDBMS and NoSQL systems.
They think NoSQL for large data out performs RDBMS always.
They believe data modeling is always easier with NoSQL.
From personal experience I would consider the cost of discovery when picking a new database.
It is far from easy to move data between relational stores and NoSQL. It's definitely not always intuitive how to model data when working with a document store. Also some of these databases are so new that their query optimization is no where near a relational system.
The things I mentioned above might not seem like a problem when you're doing a proof of concept or working with small amounts of data.
My recommendation would be to not let the hype get to you when picking a solution.
(I've worked with production implementations of Mongo, Couchbase, CouchDB and Redis.)
I'm working with Oracle and Couchbase(nosql document-oriented DB). I think that the use of the NoSql in most cases it is easier and less expensive. Every NoSql DB is a mechanism for solving a rather small range of tasks, and if under your task suited one of them, using NoSql solution will be more optimal than using monstrous large Oracle or MSSql Server. Ofter we use not more than ten per cent of the capabilities of these powerful databases, but not because we know them not at a high level, but because we just don't need all of leeway that they provide
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 11 months ago.
Improve this question
Is there an open source object oriented database for C++ available?
I had looked at Object oriented Relationship Mapping (ORM) libraries like those posted here:
https://stackoverflow.com/questions/74141/good-orm-for-c-solutions
and these were intereting as well:
Object-oriented-like structures in relational databases
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#C.2B.2B
My experience so far has been painful. The solutions don't appear to be mature and I've had difficulty even compiling some of them, and the documentation and support can be sparse.
I suppose at some level I'm trying to avoid learning SQL (I'm not a database developer). On the other hand, my gut feeling is that ORMs are an architectural 'workaround' in that they are creating a layer above a database system that inherently doesn't support objects.
My ideal database library would allow the following:
Allow one to specify the object hierarchy tree based on class names, perhaps in XML or just in C++.
Allow one to specify which fields of those classes should be persistent.
Provide an API to create, update, delete, retreive the hierarchy of objects.
Ideally, provide an API for the in-memory tree itself, including concurrent access to tree nodes.
I had worked on embedded system that had such a custom database and api.
I'm almost at the point where I'm just going to create my own and open source it.
Just wondering if there is anything off the shelf I can use.
I saw this:
http://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems
and am trying to figure out this might work:
http://www.fastdb.org/fastdb.html
Thanks in advance.
I'm not going to make any recommendations, because I don't know of a high-quality FOSS OO database. I would however make the following observations:
OO database are not a way of avoiding SQL - you need both. Frankly, If you don't know SQL pretty well, your life as a professional programmer iis likely to be unhappy.
OO databases are mature - they have been around for well over 20 years. I personally first used one on a large project in the finance industry 15 years ago.
OO database are best used where relational databases fail - I've used them in complex financial instrument modeling, oil-pipeline optimisation and telco work.
ORM databases take the bad parts of the OO and the relational models and make something even worse of them.
My favourite commercial OODB is ObjectStore, but I haven't done any work with it for quite while now.
Hope that is vaguely helpful.
Honestly, unless you're into "bleeding edge", I would stay away from OO databases. In almost all cases, they're not well supported, immature, and have various support issues client side.
The problem is, only the relational databases (and certain non-relational ones) get 99% of the attention, and thus end up far more mature. ORM may be a workaround, but if you want reliability, it's really what you need.
UPDATE:
To clarify, I'm sure there are some very reliable open source OODB's out there, but my requirements for "realiability" are more than just whether it doesn't crash and doesn't corrupt data. It includes reliability of the client connectors, reliability of the integration with the object models of popular languages, etc...
This is about open source OODB's, not commercial ones.
this is a good OO database , currently I am working with it
http://www.garret.ru/goods.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am in the process of writing an application which, among other functionality, generates MediaWiki documentation of an MSSQL database (objects, tables, table data).
My question is which document formats you prefer, or are required to produce. I have too many ideas to follow, so your answers should set my priorities ;)
(I know there are other documentation-related questions on SO, but they mostly deal with how to generate documentation (I know how to), and do not ask for specific doc types or platforms)
Edit:
Thanks for the comments. Actually I have table relations already, since I parse foreign keys. However full cross-reference may be a bit trickier ;)
However the question was meant to ask for the document types, such as Word, PDF, ODF, whatever. What are your professional requirements or preferences?
Update:
Overview of generated documentation
It sounds like you have already decided on a document format, which is HTML based on MediaWiki markup.
Also you should generate Entity-Relationship Diagrams which are useful additions to database documentation (though ERD's don't tell the whole story either).
Do you mean document organization, i.e. what headings and content should be included in each page?
Here are some suggestions:
Table Structure
Column names, data types, constraints
Meaning and usage of each column
Extra logical constraints in triggers and application code
Indexes defined
Relationships to other tables
Tables dependent on this one
Tables this one depends on
Notes on special or implicit relationships, that have no enforcement through database constraints
Usage of table
Usage in stored procedures
Usage in application code
Usage in views
Who has read and/or write access; SQL privileges of each user or role
There are other questions at StackOverflow that are very close to this one.
"How to document a database" is a very similar question to yours, since it's specifically about wiki documentation solutions.
"What are the best ways to understand an unfamiliar database" may give you some good tips, as you are creating documentation that would help someone in that situation.
"How do you document your database structure?" is related but not as closely, because it's about putting documentation into the metadata itself.
You might want to have a look at what the commerical vendors do regarding this. As Bill said, you certainly need an ER diagram. Commercial products to look at could include Embarcadero ER/Studio, Red-Gate SQL Doc, Power Designer and others.