We are here with you hands in hands to facilitate your learning & don't appreciate the idea of copying or replicating solutions. Read More>>
+ Link For Assignments, GDBs & Online Quizzes Solution
+ Link For Past Papers, Solved MCQs, Short Notes & More
Dear Students! Share your Assignments / GDBs / Quizzes files as you receive in your LMS, So it can be discussed/solved timely. Add Discussion
How to Add New Discussion in Study Group ? Step By Step Guide Click Here.
Graded Discussion Board (GDB) of CS101 will be launched on Monday August 18, 2014 and will remain open for two days.
The topic of Graded Discussion Board:
“Do you see that in future, all traditional record management tools ( Excel sheets, registers or paper work) will completely be replaced by relational databases (Oracle, MS SQL, MS Access). State your opinion in Yes / No but with proper reasoning?”
A concise, coherent and to the point comment is preferred over lengthy comment having irrelevant details. Your comment must not be more than 5-6 lines. Comments posted on regular Lesson's MDB or sent through emails will not be considered in any case. Any request about such an acceptance will not be catered.
Best of Luck
.+ http://bit.ly/vucodes (Link for Assignments, GDBs & Online Quizzes Solution)
+ http://bit.ly/papersvu (Link for Past Papers, Solved MCQs, Short Notes & More)+ Click Here to Search (Looking For something at vustudents.ning.com?) + Click Here To Join (Our facebook study Group)
No, in near future this change is impossible. As there are limited number of database experts and it will be difficult for normal users to accept this change. Millions of people using word processor and worksheet softwares will deny the change. Or huge actions may be required to train these number of people on new databases.
Please Discuss here about this GDB.Thanks
Our main purpose here discussion not just Solution
We are here with you hands in hands to facilitate your learning and do not appreciate the idea of copying or replicating solutions.
Yes, if we remember 90s decade, there was no concept of windows computer and it was very hard to move from MS DOS to windows but soon we looked our kids to play fast games on windows computers. The new data base will be more reliable and easy than our manual data on MS Excel,Word and paper work. We will only add the required information in given blocks and the complete report after the whole calculations, will be in our hand.
19 ko Quiz :/ 19 ko hi meri birthday
quiz to guzar gya... gdb he gdb
Happy birthday in adv.
Happy Birth day to you in advance
Happy Birthday Nittasha Rehman
SQL has been around as a standard for 25 years; it has wide industry adoption and sophisticated tooling to enable high productivity. SQL has been the bread-and-butter of the database world for decades, giving organizations a flexible, standard interface to access their data. NoSQL technologies grew out of the need to scale without the overhead of SQL, but such scale comes at a cost – often a big cost. NoSQL systems often lack the flexibility, administrative ease, and development productivity of SQL systems. If you are a big organization and need massive scale, you might be willing to pay those costs, but what about typical companies?
For example, depending on the NoSQL database you choose, you might get better performance, better write scaling, or a database language that more closely matches your application language. However, the database language might be less expressive or flexible, or the NoSQL database might lack concurrency or durability guarantees. Are you prepared to write a program to get a report from your database? Are you willing to use a more limited set of languages to access your data?
Many NoSQL databases do not provide ACID guarantees, for performance and scaling reasons. That might be fine for your workload; but if it is not, you will have to code concurrency and durability handling into your application or middleware. Implementing these can be complex and difficult to test.
Threats to SQL database dominance are not new. Object databases were touted in the 1990s as a way to store data in a format that more naturally fits object-oriented languages. Unfortunately, object databases were too closely tied to specific object-oriented languages, making it difficult to access data in a flexible way. Object databases soon lost favor, and object-relational mappers gained popularity.
A decade later, XML databases were all the rage, giving flexible storage for XML-based applications. Relational systems soon embraced XML storage, and pure XML databases faded as well.
NoSQL databases will never go away, just like object databases and XML databases are still around, but SQL databases will adapt. SQL databases are again learning from those dissatisfied with SQL's limitations, and are adding features to fill the gap that motivates NoSQL adoption.
Postgres has added many NoSQL-like features that allow greater scaling, non-durable storage, and JSON data manipulation – allowing users to get NoSQL features while retaining the benefits of SQL relational systems.
So, if you are considering NoSQL, you have a choice: Choose NoSQL and accept its limitations, or keep SQL and get NoSQL features with modern SQL databases like Postgres.
The future for relational databases has really never been better - though it's a future that's changing rapidly, altered by the ascendancy of big data and non-relational databases.
To listen to the media, you would think that the end of the relational database is about to strike at any moment, leaving behind a shattered mess of tables and queries strewn about in proprietary servers, collecting silicon dust.
Truth be told, the future for relational databases has really never been better — though it's a future that's changing rapidly, altered by the ascendency of big data and non-relational databases.
In describing the use cases for relational databases, it would be easy to say at this point that such databases — Oracle, SQL Server, PostgreSQL or MySQL — pretty much take care of every thing else. In the broadest sense that may be true, but that's an overly simplistic view.
First, the easy answer: relational databases are very well-suited for data sets that aren't likely to suddenly expand. Even the most successful company, for instance, is not going to see its HR database (or an asset management database) grow faster than it can handle the new entries.
One could argue, of course, that a merger with another organization that's at or larger than your organization could result in a rapidly expanding database. But such merger and acquisitions are rare in the course of normal business, and they are usually seen coming months in advance — which, of course, gives plenty of time to merge relational data sets.
Data in such collections is also structured, meaning that once a schema for the data is defined, (length of fields, type of data for fields, etc), data doesn't depart from that schema. Unstructured data can include weblog information, which can be highly varied in organization, depending on what's being monitored.
The term I usually use to describe these data set to my students is “non-exploding” data, which is colorful, but fairly apt. Data will grow and change, but not beyond the normal capability for the relational database software to keep up.
Relational databases have been around for over four decades, and that means something in the IT world.
Over those years, a lot of applications have been written to manage and manipulate data that's been held in SQL databases — some good, some bad. But if you're considering ripping and replacing apps or data architecture, it's important to remember that you don't have to fix what ain't broke.
Yes, apps can be improved, and data schemes enhanced. Better, faster databases can be installed, too. But it may not be necessary to haul your data over to a non-relational database just because it's new and shiny. If your workflow uses structured data, is the cost of moving to non-relational systems really worth it?
My favorite use case for relational databases revolves around big data.
Yeah, you read that right: big data.
Confused? Hang on a sec. See, while it is true that rapidly changing data sets do better being stored in NoSQL databases or distributed unstructured data warehouses like Hadoop, there is still a very strong and growing need for relational databases to tap into subsets of that data to perform data analysis in a timely manner.
Time after time you can read about yet-another data vendor that's built in hooks to the rock-star popular Hadoop, for this very reason. Hadoop is great for what it does: storing data across distributed commodity servers. But for real-time analysis? Meh.
Better, then, to use a known relational database tool to create familiar queries to grab some of that data and crunch it that way you need to. This is a use case that's growing very quickly these days, and which should keep relational database vendors in Dutch for the foreseeable future.
complete solution of this gdb
In my opinion, completely replacement of traditional record management tool (excel sheets) will be possible in respect of record management because of following.
So in the future traditional tools will be completely replaced.