DO NOT DEAL WITH THIS MEMBER
This is a nice project man, i'd like to see some benchmarks vs sql or other dbs.
I was thinking of doing this a while back but never started :(
(Jan 21, 2015 02:46 PM)Angel Beats Wrote: This is a nice project man, i'd like to see some benchmarks vs sql or other dbs.
I was thinking of doing this a while back but never started :(
Working on that, It will come out along with a more in depth documentation here soon. And yeah it was a lot of fun.
Jan 21, 2015 02:50 PM
(This post was last modified: Jan 21, 2015 02:50 PM by TRH4CK.)
That looks awesome.
Vouch for Tux. he is a mysql & php pro!
DO NOT DEAL WITH THIS MEMBER
(Jan 21, 2015 02:48 PM)Ego Inc Wrote: Working on that, It will come out along with a more in depth documentation here soon. And yeah it was a lot of fun.
If you could make it take commands like mysql that would be amazing.
(Jan 21, 2015 02:50 PM)Angel Beats Wrote: If you could make it take commands like mysql that would be amazing.
Meh I thought about it, structuring it with functions instead was much easier tho as that would be like writing a new language/interpreter in many respects. This way also injections aren't a problem.
Hooray to get back to earlier dates when the first databases were made xD
It's nice to see you doing this tho'.
Jan 22, 2015 06:11 AM
(This post was last modified: Jan 22, 2015 06:12 AM by Haxalot.)
It's a terrible name to have for a simple flat-file database to be honest.
General comments: - I can't see this scaling well at all since you are creating a new file for every single row, which means you're having to dip into every single file just to check each row's contents. Even the primary key (the id) of the row cannot be optimised because of this design (effectively making the primary key a unique thing only, rather than an optimised way to perform lookups too).
- Your naming conventions are cryptic and inconsistent. For example, consider mktb, which looks like a string of pseudo-random string of characters to remember from a developer's perspective. And then the get_cl_id method, which uses snake case with the verb in full form separated from the rest. And then rmcl_by_id, which uses the verb in shorthand form combined with another string of characters ("cl").
This isn't easy to remember because of inconsistency and unintuitive naming conventions. I'd recommend you adhere to the PSR-1 naming conventions of method names by using studlyCaps. So your method names above would change like so:
mktb => createTable
get_cl_id => getColumnId
rmcl_by_id => deleteColumnById
The few extra characters used makes your code self-documenting, which any programmer will be a lot more thankful for. Also, I've used the names corresponding to the CRUD operations since they're more ubiquitously used and therefore feel more intuitive than 'make', 'read', 'update', and 'remove'.
- Try to adhere to PSR-* standards in general. Your code will be more readable for it.
There's a number of other improvements you could do too, but I don't have time to talk about them for now.
PHP internals developer
(Jan 22, 2015 06:11 AM)Haxalot Wrote: It's a terrible name to have for a simple flat-file database to be honest.
General comments:- I can't see this scaling well at all since you are creating a new file for every single row, which means you're having to dip into every single file just to check each row's contents. Even the primary key (the id) of the row cannot be optimised because of this design (effectively making the primary key a unique thing only, rather than an optimised way to perform lookups too).
- Your naming conventions are cryptic and inconsistent. For example, consider mktb, which looks like a string of pseudo-random string of characters to remember from a developer's perspective. And then the get_cl_id method, which uses snake case with the verb in full form separated from the rest. And then rmcl_by_id, which uses the verb in shorthand form combined with another string of characters ("cl").
This isn't easy to remember because of inconsistency and unintuitive naming conventions. I'd recommend you adhere to the PSR-1 naming conventions of method names by using studlyCaps. So your method names above would change like so:
mktb => createTable
get_cl_id => getColumnId
rmcl_by_id => deleteColumnById
The few extra characters used makes your code self-documenting, which any programmer will be a lot more thankful for. Also, I've used the names corresponding to the CRUD operations since they're more ubiquitously used and therefore feel more intuitive than 'make', 'read', 'update', and 'remove'.
- Try to adhere to PSR-* standards in general. Your code will be more readable for it.
There's a number of other improvements you could do too, but I don't have time to talk about them for now.
Harsh as that was, thank you. I'm working on the next version of this right now and implementing your suggestions as I can.
Vouch for Tux.
Thanks for sharing.
How could NoSQL be a terrible name if it's tge origional name for such?
Google NoSQL I believe it was invented in 2000
Well seeing as you begun this as a fun project, the naming conventions aren't a massive issue.
You've done good here, it's a really nice system, and it's great to see stuff like this being shared here. Can't wait to see future versions!
I've had ideas about this in the past, but have never attempted to actually complete such a project. However, I have a suggestion.
From looking over the file, it appears each DB gets it's own directory, then each table get it's own directory inside of that, then each row of data get's it's own file, plus the additional .htaccess, .owner, etc files. An idea to clean all this up, would be to make a directory for the whole system, then each database gets it's own (XML) file, then continue down from there so that the file would look something like:
Code <?xml version="1.0" encoding="utf-8"?>
<database>
<table name="members">
<row>
<id>1</id>
<username>Username</username>
<password>qwerty</password> [b]<!--[/b] Please don't actually store plain text passwords... Or use shitty passwords... -->
</row>
<row>
<id>2</id>
<username>Admin</username>
<password>password1</password> [b]<!--[/b] Please don't actually store plain text passwords... Or use shitty passwords... -->
</row>
</table>
<table name="settings">
<row>
<key>base_url</key>
<value>http://localhost</value>
<default>http://www.google.com</default>
</row>
</table>
</database>
(Jan 23, 2015 10:20 PM)itzDecon Wrote: I've had ideas about this in the past, but have never attempted to actually complete such a project. However, I have a suggestion.
From looking over the file, it appears each DB gets it's own directory, then each table get it's own directory inside of that, then each row of data get's it's own file, plus the additional .htaccess, .owner, etc files. An idea to clean all this up, would be to make a directory for the whole system, then each database gets it's own (XML) file, then continue down from there so that the file would look something like:
Code <?xml version="1.0" encoding="utf-8"?>
<database>
<table name="members">
<row>
<id>1</id>
<username>Username</username>
<password>qwerty</password> [b]<!--[/b] Please don't actually store plain text passwords... Or use shitty passwords... -->
</row>
<row>
<id>2</id>
<username>Admin</username>
<password>password1</password> [b]<!--[/b] Please don't actually store plain text passwords... Or use shitty passwords... -->
</row>
</table>
<table name="settings">
<row>
<key>base_url</key>
<value>http://localhost</value>
<default>http://www.google.com</default>
</row>
</table>
</database>
Thanks I've actually already began updating it and it's running much faster and is much cleaning now. Expect v1 to be out in the next few days with benchmarking against MySQL.
(Jan 22, 2015 03:53 PM)hellomen Wrote: How could NoSQL be a terrible name if it's tge origional name for such?
Google NoSQL I believe it was invented in 2000
The term NoSQL was coined back in '08, I think. It's not a single technology either, but rather a term to describe a group of database - so there's no 'invention' date. NoSQL doesn't really have a definition associated with it, and with no authoritative body to give one, it will likely never be properly defined. Instead, there's common characteristics usually shared by the group of data stores that come under the NoSQL umbrella:
Open Source- NoSQL data stores have deep roots in the open source community. There are of course exceptions to this, though mostly you'll see NoSQL data stores as open source projects.
Cluster-Oriented- NoSQL data models mostly follow the notion of being aggregate-oriented, allowing the data they're storing to be distributed over a cluster of machines - thereby providing horizontal scalability. The exception category of NoSQL data stores is Graph, which are more similar to relational databases but follow a different data model. This alternate model actually makes them better at handling complex relationships within the data persisted than relational databases.
Schemaless- NoSQL data models don't have a fixed schema in place. This is the complete opposite to relational databases that have a very rigid and fixed schema in place. There's both positive and negative effects of having a schemaless design, and they will be mentioned later on.
Created in the 21st Century- NoSQL data stores first arose from the need to process and store larger quantities of data. This happened in the 21st century with the dot-com boom, and web applications saw a dramatic increase in traffic - both from web users and, later on, bots. One effect of this was that it became more valuable to capture data about web users for analysis - this soon made it clear that there were serious limitations for data storage and processing for the largest companies like Google and Amazon.
Not using the Relational Model, and therefore not using SQL- NoSQL data stores can be broadly (and crudely) grouped into four categories of data models: Document, Key-Value, Column-Family, and Graph. None of these (at the time of writing this) use the SQL language - namely because SQL is designed to work with the relational model. The language is therefore deeply rooted in relational theory where the mathematical theory of sets drive the principles of SQL's constructs. Since NoSQL data stores reject the relational model (and therefore have no concept of relations), this language isn't used to communicate (as queries) with NoSQL data stores. They instead have their own languages, as we shall see later on.
So I stand by my point - NoSQL isn't a good name for a flat-file database.
PHP internals developer
|
