Tag Info

New answers tagged

0

At 2 GB per year, you don't need a Big Data / NoSQL solution. If you pick a great RDBMS, and put it on a crappy cloud VPS with 500MB of RAM, then it doesn't matter, so get some good hardware first. Lots of RAM and fast SSD drives. You'll want a RDBMS that supports materialized views.


0

There are a number of low latency, scalable key-value data stores out there. RIAK is the one that springs to mind. Your search engine may have another opinion.


0

@ This is the possible solution I have made after getting valuable feedback from Sir Joel Brown and Vijay. Kindly verify, if it is valid.


2

The actual costs are difficult to quantify as they are often diffused. Often they appear as slower transactions. For a system used rarely, this may not be significant. For a system used for an hour a day, that is taking twice as long as is required the cost would be about 100 hrs a year per person using the system. Slower transactions may also have ...


1

I am not sure that I would consider this to be an issue of inheritance, and from the description, I would say that the Address table would depend on the other two tables instead of those two tables depending on the Address table. But that minutia aside, I would recommend: If you are only storing U.S. or maybe U.S. and Canada addresses, then you can do a ...


0

You would be more likely to have the Address table have foreign key dependencies on the Country and State tables than the other way around. Something like the below shows you one way to create the foreign key reference. Of course, the fields required for an address change depending on which country you are in; you may need to research the different ...


0

You can copy an entire database across in this manner, by copying the files to a new instance, but not collections. You also cannot simply copy the database files from database foo and alter the filenames at the filesystem level (to bar.0, bar.1 etc.) to avoid namespace collisions, the name must remain the same. If you wish to move a single collection (or ...


3

You haven't really given us much info about what this data is going to be used for. I mean, you have said what data is going to be stored, but what are you going to do with it? If your purpose is storing the data then reporting on it, then I think you're looking in the wrong place. A simple MySQL or SQL Database would do just fine and the reporting tools ...


2

If all you want to do is keep track of which authors contributed to which papers, then all you need is a simple intersecting entity (see more) like this: Here the columns of the SUBMISSION table are just the two primary key columns from PAPER and AUTHOR. These two columns will jointly form the primary key of the intersecting table and will also each ...


0

As there can be multiple authors for a single paper, so You can add one more table Submission where you can have attribute as PaperID -- FK (PK of table Paper) AuthorID -- FK(PK of table Author) SubmissionDate - DateTime2 Rest of your design looks good. Now you can create Unique Constraints on columns PaperID and AuthorID in table Submission ADD ...


1

InnoDB log files are stored on disk and so consume disk space - http://dev.mysql.com/doc/refman/5.5/en/innodb-configuration.html. However the innodb_buffer_pool_size does impact memory usage. I find this a good reference for memory sizing - http://www.mysqlcalculator.com/


1

Having had a look at your rethink with just three tables (www.graphicsdesigned.co.uk/MuseumSchema4.gif) it still needs more tweaking. What if a museum is linked to more than one category? The way you have it set up at the moment you'll be adding another row to the museums table for each category that the museum is in. What you need is a "link table" which ...


1

Teaching yourself database design is indeed very tricky. You might benefit from finding a good tutorial that would help you master the basics. If you want suggestions concerning a good learning vehicle, ask. Here is a very oversimplified summary of some of the basics. Before you can design a database, you have to analyze the subject matter in some ...


0

Let's assume that you would want to have a "Detail" entity. This would assume that these detail tuples are unique and that a given detail tuple may apply to more than one museum. Given this, you have the "MuseumDetails" entity correct. The primary key for MuseumDetails would either be the concatenation of the details_id (the primary key of the "Details" ...



Top 50 recent answers are included