next »

[perkiset]

I think we also may be talking about two radically different types of change. If your essential entity relationships are off or malformed, then yes, you may need to take everything down and refactor. But the ability to add a field to a database and not break things is crucial. My schemas are very, very well thought out, robust and usually probably about 98% where they need to be. There's always little tweaks and modifications that are required as the app lives and grows.

[vsloathe]

So how do you handle, something like, having customer records, which has a shitload of fields, and the powers that be, now decide they want a new piece of data stored "masturbationsperweek". add a new table with keys to the user record? what about when they want another column added a few weeks later? and then another?

You would never need to touch the database though. Did you look at the example?

Code:

<?php
$cc = new contentClass();
$newContentObject = $cc->createContentObject();
$newContentObject->setData('masturbationsperweek', '100000000000');
$newContentObject->setData('number_of_balls', '40000');
$cc->insertContentObject($newContentObject);
?>

Simple.

"Fields" never enter into the equation. Otherwise, my database is not normalized well enough, IMO.

I don't even need to know what tables are named or where to store stuff. My code is blissfully unaware of all of it.

EDIT: to clarify, the call to setData would be pretty much exactly the same as you adding a new field to a database table, in practice.

[nutballs]

i get your example, but where are you storing that data then?

normalization can become a problem though in large multicriteria / multiresult queries.

An example of overnormalization is having a table of IDs, and then having a table of fk_ID, DataName, DataValue, just to store addresses of users.

The farthest I would ever go is to have a table of ID,Username, Password, AnyOtherSingleOccuranceValue, then in another table, addressID, fk_userID, street,city,state,zip,addresstype. So there could be multiple addresses for each user.

I get the feeling your skipping the "this shit needs to be stored in a ginormic database, that is HA and HL". Or im just not getting what your saying.

Often I have done what I think you are getting at, which is to create a database "framework" that is infinitely flexible, at least within the confines of what the client would ever do. But that method would never hold up to high loads and mega queries. An example would be:
table 1 is fieldID, fieldname
table 2 is valueID, fk_fieldID, fk_ownerID, fieldvalue
table 3 is an owner table, with minimal info, at the very least, ownerID.

Thats my, small database and nospeczeroplanningcluelessdumbassclient framework database. Often I have multiple table2's because of datatypes. so I have table2text, table2dates, table2varchar. I hate it when I have to do it, but sometimes, I have no choice.

I can do usernames, passwords, anything else for that matter, all tied together.

[vsloathe]

Right. Flexible database framework. That's all I do anymore. I know, I know, I'm not utilizing the power and speed of RDBs. Doesn't matter, speed to deployment does.

The requirements are often speed of deployment and ease of maintenance far above performance and specifically cost. I can't recall having a client who cares about what his hardware will cost, he just wants it fast and easy. Most of the time, I can convince a client that it's worth buying far more horsepower than he would need if I made a real RDB schema in order to have the database be infinitely flexible and maintainable. People don't like having to hire DBAs, in my experience. Those guys are waaaay overpriced.

They hire me because they have no clue what they are doing and want a stable solution that is done yesterday.

[nutballs]

yep. I get it. And it often does make sense.

[vsloathe]

Indeed, and I probably shouldn't have spoken so categorically before, as I'm speaking only from my experience with clients.

When I write my own stuff, I create the database once but it is not very normalized. It's all classic RDB structure.

[nutballs]

no worries, figured as much.

one other situation is human readable.

I get the request OFTEN to create database structures that are human readable. That automatically throws out the framework tables idea because frankly, that can become a total nightmare to lookat without the code as reference. I might be creating a system that other, independent and non-communicative devs might be working in.

Often I eventually get the question from some other dev out in the void, "why did you do the tables like this?"
my answer, "Because the only question you ever asked was just now."

I actually have 3 scenarios that I build for.
1) its mine, fuck off.
2) other folks will have to work with it.
3) I have no idea what the fuck the client just said, and I don't think they do either.

3 is the framework.
2 is human readable (at least as much so as can be afforded and still be normalized)
1 is speed. no considerations elsewhere. fuck humans. fuck "proper architecture". faster=better.

[vsloathe]

I need more SEO clients. Those are much nicer than the development clients. 

[nutballs]

SEO clients suck too. At least with dev you can baffle them with bullshit if you need to. with SEO, they just look at traffic. if it goes up, youre god, if it goes down, even though you still have increased their money 10x in the past year, you suck.

meh, they all suck.

[vsloathe]

SEO clients are a piece of cake, man.

I ask what keywords they want to rank for, and then tell them how much it will cost.

Simple.

They stop paying, they'll stop ranking.