Page 1 of 4 123 ... Last
  • Jump to page:
    #1
  1. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115

    Talking Persistent data. Completely persistent data.


    I was thinking of writing a persistent data class in php that would allow for completely persistent data (syncing a DB to php). Anyone ever heard of anything like that before? I googled around a little bit and didn't really find anything.
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  2. #2
  3. Did you steal it?
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,068
    Rep Power
    9398
    Syncing data between PHP and a database? Isn't that called "a typical web application"?
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2009
    Posts
    677
    Rep Power
    7
    Were you aiming more of a LIVE item? Such may be possible, but has little to do with PHP since PHP only gets ran once on the server side before sending HTML to the client. They never get PHP. You can run more "live" calls, but they are meerly a simple refresh of an item.

    I may be wrong in saying this, but MySQL, as well as other databases out there, don't run such. They are just a library with stored information to be fetched per call.

    The closest you COULD do, which is pointless, is make an initial call to a database to fetch EVERYTHING, then ANY AND ALL queries to the database MUST pass thru this application, for it is what knows anything of the status. A MySQL server doesn't even know how many databases it holds. It itself meerly runs a check when asked to make a count or listing.
    Last edited by Triple_Nothing; December 9th, 2013 at 02:47 PM.
    He who knows not and knows not he knows not: he is a fool - shun him. He who knows not and knows he knows not: he is simple - teach him. He who knows and knows not he knows: he is asleep - wake him. He who knows and knows he knows: he is wise - follow him
  6. #4
  7. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    Yea req like basically a php-db layer that would handle all the php/mysql interaction (obviously could be setup for other than just mysql, might even just write to a file?) and you could like, for breadth's sake, only call up data you knew you needed so you wouldn't have to, for instance, load an entire array just to access a single datum of that array. This would make databases sorta obsolete, as you would pretty much just have children (mysql nested 'longtexts') instead of a bunch of seperate tables. Like you would probably only have one table with a bunch of nesting translated via php (either that or have a file that was translated).
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  8. #5
  9. Did you steal it?
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,068
    Rep Power
    9398
    Please no. Normalization, the process of splitting out data into discrete bits all over the place, is a good thing and you're proposing the complete opposite of that.

    The "a php-db layer that would handle all the php/mysql interaction" is a totally fine idea, and in fact it gets done a lot in various different ways already, but the stuff about longtexts and not having separate tables is a big step in the wrong direction. You lose out on performance in a very big way when you force your code to do all the logic.

    Consider searching: if all the data is in one field then how are you going to find what you want? There's no good answer to that. Normalization is not about making it hard to get data but about making it easy to get data.
  10. #6
  11. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    Yea that's kinda a good point. Was just something I thought about. BTW you would look the data up by ID, but yes everything would be longtexts. Eh. Oh well I'm building it right now (it's super small) I'll post a link when I'm done lol.
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  12. #7
  13. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    Lol prepare to be pissed off in the name of normalization!
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  14. #8
  15. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    I dunno this is actually looking kinda cool. Bleh still doesn't make sense though, you're totally right it reduces something like MySQL to an infantile state.
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2009
    Posts
    677
    Rep Power
    7
    Originally Posted by fireminded
    ...and you could like, for breadth's sake, only call up data you knew you needed so you wouldn't have to, for instance, load an entire array just to access a single datum of that array.
    We don't load anything more than needed. We ask the DB JUST for what we need. Anyone asking "SELECT *" is not doing it in a correct way.

    Comments on this post

    • sir_drinxalot agrees
    He who knows not and knows not he knows not: he is a fool - shun him. He who knows not and knows he knows not: he is simple - teach him. He who knows and knows not he knows: he is asleep - wake him. He who knows and knows he knows: he is wise - follow him
  18. #10
  19. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    Sometimes I use everything via select *
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  20. #11
  21. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    WORD TO YOUR MOTHER REQ

    dev.fireminded.com/P_Data/P_Data.zip

    Turned out really simple via php's serialize/unserialize functions. Just serialize the data, save it to a file, when ready read from the file and unserialize. Kinda nice just having something like session data that you can deal with instead of always going to a DB, although it's a lot less practical performance-wise.
    Last edited by fireminded; December 10th, 2013 at 08:17 PM.
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  22. #12
  23. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    So to avoid loading a bunch of values into memory, you now load the entire database? Sounds ... great.

    You also need to make sure you're not getting too many visitors, because this won't survive more than one request at a time. And the requests better not fail.

    I don't wanna put you down, but inventing your own database system isn't a good idea. At first glance, it seems to be a great thing and easy to do, but it's not. It's only easy to screw up.

    Even a seemingly trivial task like storing a bunch of values in a text file is much harder than you think. You now have to deal with things like locking to prevent concurrent requests from trampling each other. You also have to worry about atomicity, because writing only one half of a serialized string wouldn't be healthy for your "database". And if you wanna search and process data rather than wait 5 minutes until everything as been loaded into memory and processed by PHP, you also have to deal with indexing.

    As you can see, dumping a bunch of bytes into a file isn't enough. It may kinda sorta work on localhost with a few test values. But that's it. Don't even think about using it in a live environment.

    Unless you're really willing to get into the technical details of data handling, experiments like this are pretty much a waste of time. Your code won't work, and you won't learn too much from it. Instead, spend your time on things which actual get you somewhere. There's much more to database systems than fumbling with MySQL queries. Ever tried out alternative database systems like MongoDB? What about in-memory storage like memcached? Do you know object-relational mappers like Doctrine?

    Knowing those tools actually improves your skills and possibly your applications. Writing a broken session handler not so much.

    Comments on this post

    • richpri agrees : Why reinvent the wheel???
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  24. #13
  25. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115

    Cool


    Boo ya ka

    dev.fireminded.com/P_Data
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  26. #14
  27. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    Well ya'll should be thrilled I've spent the beginning two hours of coding today programming MySQL and I'll be doing so the rest of the day
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
  28. #15
  29. web.graphic.print
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Location
    Lancaster, CA USA
    Posts
    118
    Rep Power
    115
    Ok so I was thinking if you had a website that had a bunch of data stored on the server you'd have to access every table involved for the website, so it's almost like just having a persistent array to store all your data. Also I was thinking what kind of overhead does something like sessions use?
    Fire Minded
    Brent Bevans
    661.974.6771
    43654 Colony dr., Lancaster, CA 93536
    fire.minded.design@gmail.com
    http://www.fireminded.com
Page 1 of 4 123 ... Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo