I’m webGL engine developer (ThreeJS) in small company. We have some events in few weeks and my boss just told me that i have to make registration form as soon as possible, also one page should show names, lastnames and company of all registered members. Problem is that i’m very bad in databases and i have really small amount of time to re-learn it. How can i store registration data on Server without Database? I looked up on web and most instructions are unclear(because i’ve not worked on database before) and others are using localstorage (as far as i know its used for cacheing data)
What you're looking for is a flat file database system, try taffyDB it basically use Json to store its data or Papa parse that uses CSV files, you can easily edit with excel for example.
If you're really good with javascript you can consider using a real database after all,mongodb is a bit advance but still not as complicated as mysql or even sqlite.
Related
I have this web application that gets and displays data from SAP, but i need a way (maybe a JSON file?) to share some data between different users, with the possibility to modify these same data for each user (even at the same time), without a database. There will be really small data and few users, and what i would write is simple data that tells me who is online in that moment. How can i do? I'd like to know if exist an easy solution to share these really small and simple data. I'm using React with no back, because i'm taking all the data i need from SAP. Clearly, i'm a beginner. All advice is welcome.
If you talking about some prototype like MVPs, I think JSON files would be best.
However, consider to work also that you can work with Local Storage.
You could use LocalStorage, SessionStorage or IndexedDB, but the last option is an in-browser database. Maybe LocalStorage is your solution.
I'm developing a websocket real time browser game ( socketio nodejs) and wanted to start implementing my database and would like to know which type of database (nosql, sql .. ) would fit my situation best.
A small description of how i intend to use it :
I want to have game rooms with all their options stored ( which can be changed frequently)
a list of the connected users and their linked accounts( if a user is a guest he won't have a linked account, however if he does it would be linked with another table containing some extra data like lvl or something like that)
a list of user thema they like ( so for example when a game starts, it will take the themas in common for all users to use the game) all typical themas are stored in another big table that has a lot of data that won't be updated in a while.
So basically I have some tables that need a lot of quick and concurrent access which get updated and deleted frequently and some that don't need it and have a lot of permanent data.
I was thinking about using mongodb but honestly don't want to commit on something i don't have experience with ( i do have sql knowledge). I need suggestions thanks
TD;LR: I would personally go with PostgreSQL.
Recently, I had the same question as you, but with the only difference, I was not looking to build game rooms. After some research, I was convinced that PostgreSQL is awesome and suitable for every project. Well, tech giants use it too, including Facebook, Uber, Netflix... (https://stackshare.io/postgresql). It is scalable, easy to set one DB up, great community with lots of tutorials (both videos and articles) and it is also extensible, as it supports JSON, which is great!
You can use a great ORM for Node.js, such as TypeORM or Sequelize. Furthermore, I suggest you take a look at GraphQL, an API that has subscriptions (real-time operations). As I guess it will be a web application, I highly recommend you to go with React.js for the front-end functionalities, which interact great with GraphQL & Node.js. Last but not least, lots of developers and companies use both MongoDB and PostgreSQL for different functionalities and purposes for each. For user's tables use PostgreSQL, for multiple "big" JSON objects use MongoDB.
I hope that helps and lets you understand what you want in a more clear way. Good luck with your project!
I'm trying to find a solution to my problem for quite some time. This is the web app that does some calculations.
https://nicolasbg87.github.io/upwork-style-number/index.html
I'd like to know if it's possible to save user input to an online database so it can be opened and edited. It'd have to autofill all the input fields once called. I was also thinking about the option to save whole page already filled and just store it as it is.
I have to mention that it won't always have the same amount of <tr>s inside each table, and that complicates the whole process for me.
I'm running out of ideas and would be very thankful if anyone could assist me in this matter.
You have 2 options, store the data in the client, this means to store in the localStorage of the browser (this only will let availability of information for the client that store it and not share the data with other users or from the other computer). The other option is as you say store in a database but this will require to you use a backend Technology like PHP, Java, Ruby, Python, etc. And a database engine as MySQL, Postgress, and so on. And the others NoSQL like MongoDB, Redis, etc.
According to I see in the webpage the information is well structured and wouldn't be complicated to store it.
In Html, it is not possible. To store data in a database would require another language. If you used Javascript it would be possible, but it would be really insecure and very difficult. I suggest using PHP and Mysql to do it, for the best outcome. So basically Html is not a database language and requires a backend language.
I'm new in parse platform. My old apps used java apps with postgresql as database. Now i want to migrate it with parse platform.
Please explain me how to do that?
Thank you...
Depending on the complexity of your data model, a dump/import may not be a good option. If your model is simple, an import may work ok. But bear in mind that you are moving from a SQL database to a NoSQL based service. If you have join tables etc in your PostgreSQL db, these are not the way to go with Parse. The query paradigm is different.
Moving from SQL to NoSQL is mostly not about export and import, but planning your data model for NoSQL. Your best option is to plan out your new model (after reading up on NoSQL), and then create a script that will pull data from your old database and push it to your new. Unless your database is simple, this operation should not be taken ligthly.
If your app becomes very popular, the effort you put in now could be what makes or breaks your service later on.
I'm wondering if anyone has tried the get couch-connector to work with multiple databases.
I have couchapp which uses multiple databases and I'm having trouble with couch-connector to work with it. Couch-connector works great when I'm using one database, but if I try to fetch a collection from another database view I have problem, because it uses my main design document in url.
One more question: what's the best practice for implementing a chat app in my project. Is it better to have one database as inbox or should I make databases for every user. Im concered for scallability of app in case of one inbox database.
couch_connector isn't really built to do more than a single database. You might checkout backbone.couchdb.js if you're not too far along in your project. It supports multiple databases via code like:
var main_db = Backbone.couch.db('main');
var other_db = Backbone.couch.db('other');
You can see some sample code (albeit with a single DB) in the readme-backbone.js app I'm building at Couchbase.
Hopefully the two libraries are similar enough that porting your code won't be hard.
For your inbox question:
The first concern is actually your MapReduce Views--they only deal with the documents in a single database. If you'll be using a View to access data based on channels, dates, users, etc, then you'll need all the documents within a single database. However, you could split the database on something "bigger" than per-user (like per-channel).
Hope that helps.