I don't know that 'integrated' is the correct word, but has anyone had to build a knowledge base by integrating multiple disparate databases together? For example, if I were to build an ontology linking a car value ($) database with my personal finance database, I'd want to be able to build a query to find out "Can I buy a Delorian?" I'm wondering what tools/methods people have used to build this sort of thing.
Related
I am new to databases. In learning purposes I'm creating a simple booking app (with React-Redux) that would have tennis courts to book. First, you choose day and time, then you can see the exact courts (the courts are different) available for that date and time.
I was reading docs in Firebase and answers to similar questions in SO but I'm still confused.
Could you tell me, how can I structure my Firebase database and query only available courts for each date and time, or at least, what should I study to be able to make it by myself?
Your question does not have anything to do with Firebase platform necessarily.
Since you mentioned that you are new to working with databases in general, It is good for you to search for "How to design a schemaless/NoSql database". There are tons of material online for you to read. Firebase has offered two separate solutions when it comes to databases:
Firestore
Realtime database
and both of them are NoSql databases.
here is a list of things I think you have to do in order to enable yourself in this matter:
Understand what are schemaless databases and their differences with SQL databases.
Come up with a structure for your data which represent the flow of data and the use frequency of them properly in case of your application , including the indexes and etc.
Pick one of the two aforementioned databases of Firebase which suits you best after realizing how they differ from each other.
The rest is easy as eating a piece of cake!
Im wondering what will be the best way to organize my DB. Let me explain:
Im starting a new "big" project. This big project will be composed by few litle ones. In general the litle projects are not related to each other, they are just features of the big one.
One thing that all the projects have in common is the users that are going to use it.
So my questions are:
Should i create different DB for each one of the litle projects
(currently each project will contain 4-5 tables)
How to deal with the users? Should I create one DB for all the users
or should i
duplicate the users table in every DB? Have in mind that the
information about the users is used a lot in every litle project,
it's NOT only for identification purposes.
Thanks in advance for your advice.
This greatly depends on the database you choose to use.
If these "sub-projects" are designed to work as one coherent unit, then I strongly recommend you keep it all in the same database. One backup, one restore, one unit.
For organizational purposes, if you are using a database which supports it, select a different Schema per project. PostgreSQL and SQL Server are two databases (among others) which support this effortlessly.
In the case of a database like MySQL, I recommend you pick a short prefix for each subproject and prefix all tables accordingly. "P1_Customer" for example.
Shared data would go in it's own schema or prefix, like Global or something like that.
Actually, this was one of the many reasons we switched our main database from MySQL to PostgreSQL. We've been heavy users of both, and I really appreciate the features that PostgreSQL offers. SQL Server, if you are in a windows environment, is a great database IMO as well.
If the little projects are "features of the big one" then I don't see a reason why you wouldn't want just one user table for the main project. The way you setup the question makes this seem true "If there is a user A in little project 1, then there must be a user A in the 'big' project." If that is true, you should likely have the users in the big db instead of doing duplication unless you have more qualifying details.
i think the proper answer is 'it depends'.
Starting your organization down the path of single centralized system is good on many levels. I think in general i would recommend this.
however:
if you are going to have dramatically different development schedules, or dramatically different user experiences with the various sub projects, then you may be better off keeping them separate.
I'd have a look at OpenID or some other single sign-on protocol depending on the nature of your application. OpenID includes a mechanism called "attribute exchange", which allows applications to retrieve profile information from the OpenID provider.
This allows you to create a central user profile repository, with an authentication scheme, and have your individual apps query that repository for profile information.
The question as to how to design your database is hard to answer without more information. In most architectures, "features" within an application tend to be closely linked - "users" are related to "accounts" are related to "organisations" etc.
I'd recommend looking at the foreign key relationships to answer this question. If you have lots of foreign keys, build a single database for all tables. If you have "clusters" of foreign keys, and you want to have a different life cycle for each application (assuming the clusters map neatly to the applications), consider separate databases.
By "life cycle", I mean mostly the development lifecycle - app 1 might deploy weekly, app 2 monthly, app 3 once only and then be frozen.
I'm new to website design and am building/learning how to put together a data driven website that will help users with calorie/ vegetarian types of queries. My question is for big sites like DailyBurn, SparkPeople do they rent a database or build their own? I know users data is stored on their sites, so do they have separate db's for user input and calorie output? If someone is building their site from scratch is it better and cheaper to just create their own db's from scratch or pay for an existing one?
The other negative is a site like CalorieKing requires me to show their name on any queries I think even for the paid service which I do not want to do.
Thanks
H
They're probably going to be separate tables of the same database.
I'm not exactly sure what you mean by creating your own database, but with the advent of AWS they are dirt cheap.
In my CS course project this fall, we have to build a little eCommerce app (like Amazon, eBay, etc). We are free to build any type of eCommerce/store app. Since I don't have a preference for what app to build, perhaps it may be easier to decide based on freely available sample data for the store. So is there some freely available dataset available that represents a set of products, like groceries, movies, books, cars, apps, electronics, weapons, library, etc? It doesn't have to be real but as long as it can save me a few hours of entering data, it will be worthwhile. An open data format for the dataset would be useful, a MySQL database would be great.
Perhaps I should use the Northwind database from MSSQL?
Is there a "Northwind" type database available for MySQL?
I haven't looked at all the reference in this post but it looks promising: Where can I find sample databases with common formatted data that I can use in multiple database engines?
Any suggestions eCommerce sample datasets?
At this link you can find some e-commerce datasets in Comma-Separated Values format, namely some snapshots of Amazon, Google Products, ABT and Buy.
http://dbs.uni-leipzig.de/en/research/projects/object_matching/fever/benchmark_datasets_for_entity_resolution
You can try the nopCommerce sample data. Download from http://nopcommerce.codeplex.com. During installation, tick the "create sample data" box. You can then use the data within your own application. The schema is pretty easy to understand.
Requirements for archival type software
1. Data/Image/possibly video.... upload/search/retrevial/edit from web.
2. Easily implemented user defined Custom Fields
3. Easy backup.
4. Low cost ... either opensource or very low cost
I am a very novice programmer. My primary goal is to manage a collection and publish it to the web.
Options
A. Open source software such as collective access
Problems: Custom fields not supported. Continued support? Portablity of
database?
B. Use Microsoft Access and then use MVC or other development platforms to eventually
publish to the web.
Problems:Difficult to integrate to web?
C. Design my own MVC database application.
Problems:Difficult for novice programmer? Custom Fields and Upload of various data
formats difficult to implement?
Sounds like you are looking for a Digital Assets Management system. I found ResourceSpace (http://www.resourcespace.org/) and Razuna (http://www.razuna.org/) very useful for similar projects - both fall into your A category.
Requirements for archival type
software 1. Data/Image/possibly
video.... upload/search/retrevial/edit
from web. 2. Easily implemented user
defined Custom Fields 3. Easy backup.
4. Low cost ... either opensource or very low cost
Hi there,
As mentioned here before, but Razuna will satisfy your requirements quite well.
It can manage images, documents, videos and audios. It will share folderd and collections on the web with access permissions and will allow you to search among the different kind of assets as well.
Moreover, it can handle metadata of all this asset. It will not only read metadata, but also WRITE metadata, also. Furthermore, you can set the custom fields for each asset type and users will have a web interface to work with.
Razuna supports different databases (H2, MySQL, MS SQL and Oracle (soon DB2)) and let's you migrate from one db to another with ease (backup / restore option).
Best of it all: It is available under a open source license for you to deploy and enjoy today. You can get it at http://razuna.org.
Kind Regards,
Nitai
PS: I'm the main developer and founder of Razuna.