Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Say your data is fairly relational in nature, but the scale of your application has outgrown the performance ability of your database... Given that most NoSQL solutions out there seem to promise much better performance (I'm working on a real-time content recommendation engine), I'm looking at alternatives. I can think of ways to smack my data model around so it could be represented as documents, graphs, or even simple/abusive key-value pairs...
But where is the [complexity vs performance] trade-off worth while/smart?? Does it sound reasonable to increase the complexity of the application so that we can use a document-oriented database in the hopes that performance will increase?
What are some proven principles/rules of thumb to guide the design decisions in such a situation?
I would recommend Fighting the NoSQL mindset and NoNoSQL
Neither of these are biased towards traditional RDBMS despite their titles, they both give pretty decent perspectives on the tradeoffs. This topic has raged for years all over the internet but quality articles are hard to pick out of the noise. Good luck!
edit: almost forgot NoSQL data modeling techniques
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 4 years ago.
Improve this question
Why do we use OOPs concepts?
What are the advantages/disadvantages of OOP?
Where do we use OOP?
How do we tell if a program can be written in OOP paradigm? How is it organized?
Note : I'm not related to technical field... So please consider this in your answers.
In short: to reduce the cognitive load required to write, maintain and understand the software.
Software systems are inherently complex, so developers need some tools to break things down to the modules and individual components that could be analyzed and understood without enormous efforts — and OOP is just that kind of tool.
Thats quite a big question. And I try to give you a feeling why we do develop principals like oop ,soa,....
Most of the principal target to make software less complex. Imagine a file with 1.000.000 functions. it would become difficult to find the you want to change. Especially if there are not veryx wqell name like "Update" so you could have a thousand "update" methods.
Often things are less complex if you don't see the complete information pool so you can focus and things you may need. Thats also why there ideas like the information hiding principle .
Another thing is that when you have standards you have to think about. For example in Real life you know that you can sit on a chair (thats a standard) you don't ahve to think about it. Thats why standards make like easier. Some aspects of OOP establish standards (e.g. use of classes) therefore there is little less complexity.
Having class which are grouping the functions may be the first step towards oop. Now when you search a function you would most propably know what you want to udpat "a custoemr" so you know this function may be in the customer class and you have to only look over these methods.
And most of the time thats what principals are made for. making software more read and understandable
OOP is much much more and not the only paradigm .But there is so much more and OOP has so much principals and interprations. It would be too much to explaind and discuss it here. I would also recommend you to have a look at the CleanCoders Movement which provide this in a more general way.
CleanCoders Webcasts
Does ORganization matter
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
Why don't any of the major RDBMS systems like MySQL, SQL Server, Oracle, etc. have good full text indexing support?
I realize that most databases support full text indexes to some degree, but that they are usually slower, and with a smaller feature set. It seems that every time you want a really good full text index, you have to go outside the database and use something like Lucene/Solr or Sphinx.
Why isn't the technology in these full text search engines completely integrated into the database engine? There's lot of problems with keeping the data in another system such as Lucence, including keeping the data up to date, and the inability to join the results with other tables. Is there a specific technological reason why these two technologies can't be integrated?
RDBMS indexed serve a different purpose. They are there to offer the engine a way to optimize access to the data, both by the user and by the engine itself (to resolve joins, check foreign keys, etc...). As such they are really not a functional data structure.
Tools like full-text search, tag clouds may be very useful for enhancing the user experience. These serve only the user and applications. They are functional, and require real data structures... secondary tables or derived fields... with, typically, a whole lot of triggers and code to keep these updated.
And IMHO... there are many ways to implement these technologies. RDBMS producers would have to maybe choose some tech over another... for reasons that have nothing to do with the RDBMS engine itself. That does not really seem their job.
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 3 years ago.
Improve this question
There is a lot of articles on the web supporting the trend to move to a graph database like Neo4j... but I can't find much against them.
When would a graph database not be the best solution?
Any links to articles that compare graphs, nosql, and relational databases would be great.
Currently I would not use Neo4j in a high volume write situation. The writes are still limited to a single machine, so you're restricted to a single machine's throughput, until they figure out some way of sharding (which is, by the way, in the works). In high volume write situations, you would probably look at some other store like Cassandra or MongoDB, and sacrifice other benefits a graph database gives you.
Another thing I would not currently use Neo4j for is full-text search, although it does have some built-in facility (as it uses Lucene for indexing under the hood), it is limited in scope and difficult to use from the latest Cypher. I understand that this is going to be improving rapidly in the next couple of releases, and look forward to that. Something like ElasticSearch or Solr would do a better job for FTS-related things.
Contrary to popular belief, tabular data is often well-fitted to the graph, unless you really have very denormalized data, like log records.
The good news is you can take advantage of many of these things together, picking the best tool for the job, and implement a polyglot persistence solution to answer your questions the best way possible.
Also, I would not use neo4j for serving and storing binary data. There are much better options for images, videos and large text documents out there - use them either as indexes with Neo4j, or just reference them.
When would a graph database not be the best solution?
When you work in a conservative company.
Insert some well thought-out technical reason here.
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
We want to implement a model or guideline for our OO designs,. We like Domain-Driven Design. Our specific question is: do you think DDD is still valid right now beyond the pattern design? If so, do other approaches or variants exist that we should evaluate ?
Fundamentally we develop enterprise web and desktop applications using Visual studio (c#).
Thanks in advance
In my opinion, DDD is as pertinent today as ever. The idea that one should strive for an Ubiquitous Language, such that the domain in code is not divorced from the domain as described by the domain experts, will probably remain a good idea for a long time, and it is easier today to focus on the domain first and consider persistence as a "secondary" problem than it used to be. It is also still true that DDD requires an important design effort, and its value is going to be proportional to how complex the domain is.
I have not written any application using the methodology, but I have been reading a lot on Event Sourcing and CQRS lately, and they both seems like a very interesting approach which should fit well with DDD (and are usually advocated by people who are DDD proponents).
I can't find it right now, but there is a video interviews of Eric Evans floating around somewhere on the web,You may be interested in watching this video of Eric Evans, which is a form of retrospective on the methodology a few years after writing the book, and what he would have done differently now.
I think DDD is quite alive (or quite as dead) as before. My opinion is that the "domain" is a hot topic today because of DSLs (Domain-Specific Languages) and MDE (Model-Driven Engineering).
You may want to learn more about a similar "domain-driven" aproach, called DSM - Domain-Specific modeling. In DSM, you can work through patterns but you also define code generators that translate your domain-specific design into working code.
Check the DSM Forum or Wikipedia for more information about DSM.
The two most notable tools right now in this area are MetaEdit+ from MetaCase and AtomWeaver from Isomeris.
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
After reading the definition of procedural design (http://en.wikipedia.org/wiki/Design_document) and searching for a few example diagrams, I have been having trouble on finding out more on what procedural design means other than finding this diagram (http://www.kelso.scotborders.sch.uk/departments/computing/resources/mindmaps/Procedural%20program%20design.gif). Typically, when is this type of documentation necessary? Is it when there's a specific algorithm used in the application?
This is most often used when you have a few very similar constructs that are used really often. In a way SQL is a "procedural design" since it limits you to tables and column and a handful of operations which can be applied to the "data model" (= the database).
Code generators thrive in this area since they have a large but simple input and generate a lot of code that would be extremely tedious and error prone to write by hand. In a similar way, you can generate "documentation" for this which is usually a big waste of time since it will be enormous in volume and contain very little information about how the system works.
[EDIT] In computer science the amount of information in a message is the amount of "surprise" you get per bit. So one page of "1'000 feet view" which is tight packed with information, which gives you a compressed introduction how the system is designed and how you can find your way around, is worth more than 1'000 pages of documentation generated from a data model.