| |
Perff
Administrator
Posts: 1679 |
CSDb V2
As some of you might have seen, there have been talked a bit about a CSDb V2.
I have also had this idea for some years now, because of some basic flaws in the originally database design of CSDb.
Now is the time to try to do something about it.
But we, the current CSDb staff, don't have the resources to do this, so we need your help!
Here is what we need:
1. Somewhere to host CSDb V2. The current hosting for CSDb is not very good, as some of you might agree on, and it would be very difficult for more people to develop on it, so a new hosting place is needed.
The requirements for such place are not to much. Talking about performance, CSDb can run on any normal computer today with no problem, and a few gig of disk space should be ok. The daily trafic sums up to about 40-50.000 hits and 300-400mb.
Some kind of CVS or similar to make it easy for multiple people to develop on it, is also required. (PS. We got no money! )
2. People that would help. First of all we need some willing developers - PHP & SQL. I don't think we should get too many - 2-3, perhaps 4 (plus myself :) ) We'll figure that out.
Also some design people, to make the site look kewl. :) And finally some people with deep knowledge of the scene so we are sure to get around every corner in the design phase.
3. Time and patience. :)
The plan is then to put togehter a CSDb V2 team (not to big, 6-8 people tops), and figure out exatcly how to make it. Of course we should look at the current CSDb, but I sugest we make everything from scratch.
Most importaint is the design phase. We must try to take all into account when designing it. I think this is the most importaint part of it all.
Then it gets coded, designed etc, and when it is ready for release, we transfer all the data from CSDb to CSDb V2. :)
Even though the CSDb team is the ones who should make it, it dosn't mean that the rest of you have nothing to say. Perhaps we could post our plans somewhere for all of you to comment on.
That is roughly how I see it.
Now lets have a nice little discussion. :) |
|
... 91 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
Quote:could you be more specific? Who are the people we need to get involved?
You already talked to half of them and were not listening. The other half can speak up if they want to - but knowing them, that will not happen, because they prefer to work behind the scenes. Those people will follow when the other half has actually made something worth talking about.
Quote:Most of the "tips" were negative judgements and ridicule regarding my ideas for how I envisioned it working.
When everyone tells you a relational db is what it needs, because the data is highly relational - and you dismiss it and in the next sentence say you need to do more research... yeah that is what will happen. It makes it look like you are not planning to listen to the people who actually know all the things you still need to research. |
| |
instant
Registered: Mar 2020
Posts: 20 |
@Shine: Thanks! I hope to learn some stuff in the process and want the end result to be something that people will love as much as all of the great work that has been done to date. :) |
| |
Burglar
Registered: Dec 2004
Posts: 1088 |
Quote:But when someone says "Oh that won't work. You need to do this." and doesn't explain why it won't work on the contrary, I gave you many explanations as to why NoSQL is a bad choice for this type of highly relational data.
I also offered my help, just not on a appwrite/nodejs/nosql solution. It is not the right hammer for this nail.
We also explained that your approach would require all relations to be coded into the app-layer, that on change, cascading updates need to be scattered around the nosql store. And I didn't even mention search yet :)
This is why everyone in this thread is suggesting a different approach: start with gathering requirements and the database design, bottom-up. Get people like perff, hedning, count zero, etc involved. Without them, any project aimed to replace current csdb is bound to fail.
That said, your enthusiasm is great :) Whenever you need feedback on your plans, you know where to find me, I'll give it to you bluntly :) |
| |
instant
Registered: Mar 2020
Posts: 20 |
I will have more posted soon but let's get things moving.
Please add an issue to the repo for each individual requirement, feature, suggestion, etc.
https://github.com/idolpx/csdb-ng |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
Having patched a lot of "unpatchable" things in my job I wonder why if it is not possible to open source CSDb "as it is" and then have people trying to make it better. I understand that sometimes it is good to "start from scratch", but I think even with the most ugly codebase there will be room for improvement if more people would look at the code and reflect about it. Especially when it comes to "visual" stuff which happens to be one of the first "issues" in instants bug tracker: "make it mobile friendly". This is really "simple" front-end stuff which could be achieved without touching any of the discussions which structure the database should have.
I doubt that "one lone coder" effort will result in "CSDb v2" or something like that. Gradually improving what is already there may sometimes be a pain in the ass, but I can't believe that it is a really impossible task. |
| |
Youth
Registered: Aug 2003
Posts: 43 |
I agree with spider-j
I have been looking at the current site trying to find issues I would like fixed, and a few things struck me:
- It basically works for me as a user. I browse stuff, find stuff, download stuff and occasionally interact on forums, place comments and upload my own stuff. Apart from the design and interaction feeling a bit old-fashioned, nothing frustrates me.
- It is big. It has evolved to have lots of functionality that is actually being used.
- It has been around and in use for a long time. Things are being added and commented upon daily.
- It seems to be always up and performance is ok.
- My main point of improvement is to have a mobile UI. Read-only is fine for now.
Rebuilding a system like this from scratch is almost never a good idea. It might need some serious refactoring to enable future improvements and keep/make the site developer and maintainer friendly though. |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
#donttouchmycsdb |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
How likely is it that the source code of current CSDb will ever be made public? Same with the underlying database. I have a feeling the answer would be "you can pry it from my dead, cold hands". But I'd like to wrong on that one ;)
As for starting from scratch: sometimes that's the way to go, (try to) implement things properly from the start. From what I've heard the current code is hack upon hack upon hack. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
Quote: I will have more posted soon but let's get things moving.
Please add an issue to the repo for each individual requirement, feature, suggestion, etc.
https://github.com/idolpx/csdb-ng
I have never worked on such a project but some things about the db scheme seems not right to me.
dates are strings and ints, sometimes a date is just a year or a month, shouldnt all be date type ? (if db engine supports it)
scener has both handle string and pointer to handle entry, why not just the pointer? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
