Anyhow, I've found that keeping hydrated has a lot to do with the amount of salt I injest as well as water. Without salt (as I figure) your body doesn't have enough sodium to retain the water -- the water just keeps on pushing through. My gauge on this is the veins in my hands; if they're flat, I'm low on both water and salt.
Anyhow, as one other dude mentioned (about some other problem), you can also keep your fluids in your body if you keep your *main* fluid in your body, IYKWIM. Vitality and surprizing looks from women are the rewards of treasuring the seed, grasshoppa -- gf or not.
Peace & Blessings, bmac For *all* the answers: www.mihr.com
Alec Baldwin played this bouncy guy who would help you lose weight -- by following you around and publicly beating you up. So Farley stands up (in the infomercial) and says "I'm kindof a big guy, how will you help me?" Baldwin immediately says "I'll beat you with a shovel".
Of course that's the same episode where Baldwin goes on NPR and talks about his tasty holiday treat: "Schwetty Balls".
Dang funny, that Baldwin dude.
Peace & Blessings, bmac For true peace & happiness: www.mihr.com
Yeah, but in *every* company I've worked for, the free coffee flowed like a flood-striken river. Screw the employees stomachs, bladders, and kidneys, make `em work faster, harder, longer. Sh*t, they would've provided crack and hydro if it was legal. Anything to get more $/t.
The important thing is that I'm not bitter:-)
Peace & Blessings, bmac Check out www.mihr.com for the secrets of existence.
I wonder what effect eye color has on color sensitivity. If one has a blue iris, it must affect the "input", right? As well, there should be some sort of effect for green, gray and brown irii, right?
And, yeah, I know that the pupil is where the light goes thru, but the iris is bigger (at times) area-wise and must be letting some light thru, right? And the iris is doing some sort of "color correction" on what light makes it thru, neh?
Any ideas?
Merry Christmas, Peace & Blessings, bmac For lasting peace & happiness, www.mihr.com Manual Sig Generator 4.1ish
Thanks Mr. Wall for allowing me to spend three lovely months in Helsinki, Finland. And thanks Finland, you are unbelievably beautiful.
If anyone ever gets the chance to work for/with Nokia, do it, it is a nice corporate culture and if you get to go to Finland, you will not regret it.
For you language purists, if you use a small subset of perl, you can generate very clean and even simple code. It all depends on what syntax/features you choose. And, remember, how you organize your code determines how clean the program is anyhow; the language is just the vehicle for expressing logic, the program is the destination and *how* you get there.
Peace & Blessings, bmac For true peace & happiness: www.mihr.com Manual.Sig Generator because sentiment should not be auto-generated:-)
I'm drawing a blank but she'd have to be pretty young and wispy-thin.
This definitely illustrates the beauty of these books, in that the images you can create yourself will *always* surpass the reality of film.
I've listened to Gibson's Neuromancer audio book (which he, himself, read, with the Edge doing the music) well over 100 times as backnoise for programming (gotta love the subtle techno feel), and I doubt seeing a movie version, no matter how well done, will be anything but painful for me.
So this ragged train of thought begs the next question: who for Case and who for Molly? For some reason, Gary Busy (with lot's of makeup) always seems my picture of Armitage (I think he could do the "blank-as-a-button bit pretty good").
Peace & Blessings, bmac for true peace & happiness: www.mihr.com Life has a purpose, if you don't know that purpose, you're already losing. MSG 4.0
I have hope that this may be added into an Extended-Edition (probably due out this time next year).
Unfortunately, I read that Jackson *never* liked that part of the books and never intended to film it, so I seriously doubt it will happen.
This really sours me on his understanding of the books as a major point of having hobbits in the first place (as far as I can gleam) is that they are going to have the need to have their own power in the 4th Age. That's another big part of Gandalf, many of the elves and the ring-bearers going across the water at the end. Sure, it's a melancholy ending, but it most of life doesn't end up all happy anyway, far as I've seen.
And hey, I said it first (AFAIK), how about making some scenes with Tom Bombadil with Patrick Stewart! I mean, the dude can sing and he kinda looks like a leprachaun which is always the picture I make of ol' Bombadil who is one of my favorite characters.
And, yeah, they fscked my *favorite* character *way* up: Faramir. But enough ranting, I didn't have the budget to make it better:-)
Peace & Blessings, bmac For true peace & happiness, go to www.mihr.com Manual Sig Generator v. 3.9ish
Just because a technology does not fully captures a requirement doesn't mean that you should avoid it entirely. You really are doing a dis-service to your client since you are not using full use of the tools they bought/implemented.
Actually, my clients are always *totally* satisfied with the results of my work, and no client I have ever worked for has given two sh*ts how I got the job done, so long as the programs worked. There are *never* any bugs in my finished product. I know it sounds ridiculous, but it's true. That's because I always use the simplest features of the chosen env and then build upon patterns that I find to work. And I test the crap out of it after every code addition.
As a further example of my disdain for the norm, I very rarely use inheritance in C++. Think that's absurd? Well, if you've read the Go4's book "Design Patterns" (truly a seminal work in CS), you would see that one of their guiding principles of oo design is "use containment over inheritance", which is where you use the parent class as a data member as opposed to as the base class. Sure, inheritance has its purpose, but you just don't use a thing because it's there, you use it for a reason after careful consideration of the other ways a purpose can be achieved and what the relative costs are. And, in my experience, FKs put into a database schema are a waste of time, whose only possible purpose would be to enhance query optimization.
Peace & Blessings, bmac For the secrets to life itself: www.mihr.com MSG 3.8
Not strictly. Say you have a sales/accounting which feeds data, then you have budgeting people which needs to forcast. Say that they have two different IT departments. One uses an internal one, the other thinks that the internal is crappy and outsources. They can develop two different applications/design doc/programmer teams/end-user requirements, using the same database.
You can *not* have two different design specs implemented that *modify* the same data. Read-only apps don't count. There would be no consistent data without a consistent insert/update/delete policy. And, yes, 1000 people can read the data 1000 different ways, but that doesn't factor into the stability of the data.
Your main reason for not using them seems to be "programmers should be good enough" so they are not needed.
No, my reason for not using them is that the logic that connects those two tables (in the FK relationship) will be far more complex than just "table A has a 1:n relationship with table B". And programmers *must* be good enough to implement the level of complexity that *actually* relates the two tables, or you don't have a viable app.
It seems that you are an experienced db app developer, so I ask you: how do you set up a FK relationship between a table that has a field that, depending on another integer field, can be a link to any of N other tables? Is there a standard for this? And what if one of the integer values is for a "no link at all" condition. This real-world example demonstrates the meaningless of a FK statement (that would be required) such as "table A links to tables B, C or D via field X, depending on the value in field Y".
Peace & Blessings, bmac
For true peace & happiness: www.mihr.com MSG 3.85:-)
1. Programmers make mistakes. If they were perfect you wouldn't need a whole lot of things besides FKs. But people are human. Having a data architect and a programmer work on relations is better. (two heads are better than one?) Getting messed up data is one of the worst things you can do to the reliablity of an application. You can fix a display problem or a "missing button" functionality but once that crappy data is in, its a pain to fix it, if you can.
Sure, we all make mistakes, but the really good programmers find their mistakes and fix them in the alpha stage (screw beta!).
2. FKs don't cost alot. Only in the cases of extreme number of fks.
Yeah, but anything is more than nothing, though, if, as one other poster suggested, they can improve query opt, they *would* be worth it then (but not as a reliability tool). I doubt this, though, because if my query is doing joins between indexed keys, and I've ordered my join properly, the optimizer *better* do it right, for all those thousands of dollars (excluding MySQL, of course, which, IMO, is *excellent*).
3. Helps others understand the database schema. Relational databases are not object orieniented. There is a "translation" that needs to be done from the database tables to the application objects. Just because I understand the business rules and object model doesn't mean that I understand the database model.
True, especially your last sentence, but any constraint put within a db scheme *by definition* will fall short of the truth of the relations fleshed out by the actual middleware. By definition. Proof is evident by virtue of the corollary being false: why can't all the middleware be implemented using constraints? It can't (and will never be). That's the job of functions, and documenting their purposes/effects is a thorny realm.
4. The reality is that if you are talking about a serious enterprise application, the logic for the tables might not be in one place. Either because of point 3. or because there are multiple applications accessing a singlular enterprise database.
Well, first you need to see my "2nd Law of Computer Programming" (in my journal) which states the direct relation between code organization and probability of success. Where the logic resides is irrelevant, IMO it is still just one app if it modifies the same data. Besides, there certainly isn't more than one design doc, right?
5. Programmers are hacks. Ok not all of them but some of them are. And if they see that a quick fix is to use this table in this brand new way or this field as having its own special rule, they will. This is not good because it can and will break other parts of the program or reporting. (This is an extension of point 1.)
Well, you state it yourself: it is *not good*. And no programmer of that caliber is going to work on my project. Not for long, at least. It would be a stipulation of his hiring and the grounds for his dismissal.
To sum up my feeling on FKs: they're a band-aid for a bullet wound.
Peace & Blessings, bmac
For lasting peace & true happiness: www.mihr.com MSG v3.6
I saw all your comments in this thread and you obvioulsy think too much of yourself. You still have to learn how fully exploit a *real* DBMS.
Hmm, I know what has worked for me and I *know* that my apps *never* have bugs. And that is no hyperbole. And I know that no one has *ever* written a book on how to write a bug-free app of any significant complexity. I'd love to read it, though, if/when it happens.
And, BTW, I'd really rather not come across arrogant or cocky, but text is a bad way to represent intention, and the attitude of the reader cannot be depended upon, yet it often determines how a confident opinion is interpreted. So, just for the record, my intention here is to state some beliefs my experience has ingrained and then to have content-based (as opposed to emotion-based) discussions about them. And, sure, I'm gonna fail at that last part sometimes, but I'm trying.
Ever heard something about triggers ? Or stored procedures ?
Of course I've heard of them, even tried them. But, first, I tend to not use non-standard, vendor-supplied additions to technology, especially when good ol' SQL will do the job nicely.
Technically, though, I don't use triggers because how do you error-trap an auto-exec'd fct? Sketchy at best. When will that error occur (this relates to knowing *exactly* when the trigger fct will execute). How will it get reported? If the trigger exec's before my SQL statement returns, then how do I know where the error occurred (someone here actually likes parsing SQL error statements, though I find that more error-prone then just pre-checking the failure points).
As far as stored procs go, I'd *love* to use them. To have a single list of functions be the interface to my entire persistent storage would enable an excellent interface definition. The problems are 1) that Oracle's stored proc lang is so friggin ugly that it can't be good, and 2) interfacing stored procs from a normal prog lang is too raggedy to depend on. They're just not elegant enough, and in my experience, elegance determines probability of success. And success is defined by only one thing: no bugs in a correctly coded app. Triggers and stored procs (so far) only lead to greater indeterminism and, therefore, greater chance of failure to *know* that there are no bugs.
MySQL is all fine, but prototyping in it and then porting the DB to Oracle is kind of silly IMHO.
It's not silly when the first half of the project is being written from outside a bullet-proof corporate intranet wherein the app will reside, and you have no like machine configuration to dev on. Plus, it was a challenge to seamlessly manifest the logic using manual cross-platform development techniques. It was friggin' cool, and I didn't mention that we did this with two weeks to go before my time in Finland ran out, but I still vacationed the last weekend I was there, because it was *done*.
Peace & Blessings, bmac
Sig for me means Significant Manual.sig generator v3.5:-)
Well, there are two ways of looking at the typical system.
I don't see it in either of the ways you mention. I see software, regardless of architecture, as made up of three interconnected realms:
1. Spacial
This is the layout of your data types. In C/OO, it's your structs, class data members, representation for enums, etc. In a RDBMS env, it's your table schemas.
2. Temporal
This is the collection of routines that modify your data structures. In an C/OO env, it's your library fcts and class member fcts. In a RDBMS it's the "middleware". In any case, this layer is the definition of how your data can change, where each change is of one of four possible types: creation, modification, deletion and selection/reading/querying. In this layer you define first how to construct a new instance of a data structure (variable or record, depending upon env) then you define the circumstances and ways it can change.
3. Visual
While this could be put under Temporal, I find it useful to break it out into its own category, mainly because I see it as being closest to your users (the Spacial being furthest away from them). In this layer all your logic resides that concerns the presentation of both data and the visual cues (like buttons) that allow the Temporal fcts to be accessed/executed. Note that the objects that will allow this layer to be built will themselves have their own spacial & temporal layers (think of the data and fctality behind a combo box).
Now, in applying this perspective to a web application, I see the database being an (obviously) spacial layer that resides in parallel with an in-memory representation of records containing table data (this parallel rep being completely dependent upon lang being used to access the db).
So, absolutely, I can see the possibility for an object-oriented auto-mapping from an OO-type of definition to a RDBMS-type of definition of the different layers. That's what a good programmer is doing mentally and organizationally if not physically (by using a tool).
And Prevaler looks to me to be just a memory RDBMS system, but I disagree with them that the db does *not* have to be stopped to dump the memory image to persistent storage. I feel that in some db apps, you would get bad results occasionally from some race conditions, which would be very difficult to track down.
Now, to my mind, nothing is going to be revolutionary in making a new language for the spacial, temporal and visual. Why? Because computers have volatile memory, permanant storage and a visual interface (even if only on the client machine). Any application you can think of is going to reside in that flow, i.e. mem to/from perm, visual to/from mem. What will be revolutionary are new ways of constructing spacial-temporal-visual frameworks (which we call applications or programs, even of the OS variety). A sufficiently advanced program could even be spacial-layer *and* temporal-layer agnostic.
Of course, as I'm writing this, it occurs to me that databases aren't so great for expressing all the constraints on the data anyhow;
Yes, because a schema definition cannot be used to define the relations defined by the temporal layer -- it's strictly spacial. A good example of this is a table that has a field that can link to different tables via the value in one of its sibling fields. This is a purely temporal relation and while it relates to the structure of the table, the actual linkage can only be described by a "links to either table A, B, or C" constraint. To put it more succinctly, relations between tables are always defined in time; on the simplest level, it's because when added joined records, one record will always be added before another.
Peace & Blessings, bmac
For true peace & happiness, www.mihr.com Why use a static.sig when you can make a new one manually each time?
Though I'm not a statistician, I have done for-pay work (may years ago) using SAS and SPSS to help people analyze their data. As a result, I can tell you that NULL is used as a label for "data not present", which is used in certain stat algorithms to determine, as I understand it, a) the probability that your conclusions/results are meaningful, and b) that you have enough data to draw conclusions.
If, for example, your varchar(n) field type didn't have the ability to store a null, you would have to specify (in your logic) a value for "data not present", which for some apps would not equal "". Add to that the perfect probability that some person would enter the exact string into the field that you are using for "data not here" and you can see the problem that having nulls can solve.
I've never dealt with an app that so badly needed to know that there is no data in a particular field where just initializing it to "" or 0 wouldn't work. And my point here about nulls is that for probably 99% of your modern data-centric apps that do not need hardcore stat analysis, the use of nulls is a waste of time.
Peace & Blessings, bmac
For true peace & happiness: www.mihr.com Manual.sig generator v.4.3
I hope you're trolling, and not actually deploying software.
Sorry to disappoint, but I do, and it may just happen that you end up using my software on *your* machine, someday, God Willing:-)
This statement is analogous to "I have to say, I've never seen the use of backups to be needed on any filesystem I've worked with."
Though I'm a huge fan of hyperbole, that is an absurd analogy.
What the hell are you talking about? Quick - what's your employer's mother's sister's middle name? Hm, maybe that's a null value.
How about ""? Works for me. Empty data != null data, though one commenter noted that in Oracle (I believe) "" does actually == null. But that is absurd because null is supposed to be outside the domain of *actual* values for the field type.
I won't even begin to get in to the evil I've seen applications do to work around stupid NOT NULL declarations...
Umm, a table is a collection of data, organized into records. Each field has a range of possible values. RDBMSs allow you to give each field an optional extra value called NULL, which is a nightmare for the code that must deal with that non-value value. My apps don't "work around" the NOT NULL, they *utilize* it, to greater simplicity and, as a direct result, far greater bug-free-ness.
The default value thing I was mentioning had to do with altering a table that has data already in it. Giving the new fields in the existing records a default value has not been possible in the envs that I've worked in. This is related to another problem with adding a column after table creation, namely, that the column must be able to hold nulls, which screws up query logic, as I've found over and over.
And, as you say, most foreign key relationships are for indexed fields or groups of fields, which to my understanding would mean that that is enough information for the query optimizer to perform the query in the proper order (and let's just say that index design is where you prove where you know how to design a RDBS). I mean, no one with any clue joins on non-indexed fields, right?
And, as a matter of fact, though I design my primary keys and any secondary indexes with great care, I *do* perform the primary key checks before I ever issue an insert. Why?
*silence*
Because the insertion of a record can fail for any number of reasons: a bad key or a too-long char/varchar as two examples. Now, with two unique keys (say a primary int id and a unique name) and N string fields you have N+2 possible ways that the insert can fail. I don't like to parse db error message strings, so I perform N+2 select queries beforehand to ensure that if the insert *would* fail, I know exactly for which reason. Why? So I can tell my n00b users what they screwed up *in detail*.
And, you are most certainly correct! I do charge by the hour, because only God Himself knows how long anything is going to take, especially the successful design, understanding, implementation and testing of any halfway sophisticated piece of software. Any other pricing policy is just plain old horsesh*t. Either that or a friggin shot in the dark. My favorite formula for project estimation is: take the time you think it will take you, multiply it by three and add two.
I've found that subtle problems are the result of not properly designing, then incrementally building with iterim testing. And, it certainly does not take a "god" to make bug-free software, but I don't tolerate bugs in my software, because that causes my employers to have to call me, and I'd rather let them have their business logic as they want it and leave me to enjoy life.
More specifically, do you not design your software such that all your business logic for a particular table is located in the same place? How can you possibly strand a child as a result of calling a delete within that lib that calls the appropriate deletes in the child libs? If you are running an app that has stranded children you have progressed too quickly past a point where your implementation hasn't been adequately tested, neh? I mean, you have the purpose of the db in design form on some level (use-cases, formal specs, whatever...) and you implement that piece, test it with all types of parameter sets and, voila, you *know* it works. Plus, you've got the ability to generate log files for any path of logic you choose during Beta so any problems have a trace, and a proper debug trace gives you the ability to track and squash the bug, right?
On a more simple level, assuming you're a programmer, if I asked you to write a program that let the user enter strings into a list that was kept in sorted order, you could generate a program that you *knew* was correct, right? Well, with more complexity in the logic (software logic has exponential expansion, as I see it) it just takes more experience and delicacy in the development phase, where the order of implementation, care in refactoring and beligerant and relentless testing are the difference between success and being fscked.
And the DBMS can *not* manage anything because the DBMS does not spec out and implement business logic. Besides, in any sufficiently complex app, there are constraints on the values in linked tables; these type of constraints are not defineable in any db I've ever seen. As well, one can often have one field that will link to many different possible tables, depending upon values in the parent record. Perhaps that kind of constraint can be quantified in a structural definition, but, to my way of understanding it, it is more of a temporal (or dynamic) condition. Even if it could be spec'd into the schema it's no better than an assert statement (which I loathe), and certainly does not help you generate the functionality necessary to successfully construct the data.
Unfortunately, it seems that my sharing my experience is wasted on this rather abrasive crowd. I spent six months developing a monster of an ugly intranet db app for a Finnish-based international company. Up until the last two weeks we developed it using Linux and MySQL and in the last two weeks transferred it to the runtime env on Windows NT and Oracle. That was two weeks before I had to fly home from Finland, where they put me up after flying me there after the first three months. As a subcontractor, I was liable for all bugs within the project at my own expense for a year after delivery. After two months of testing, they found six bugs, all but one *very* minor. I spent eight or ten hours fixing them and then *I was done*. And this was no trifling app; it was the most aweful convoluted business logic *ever*, built with raw html and perl (not my choice).
I'm really not trying to toot my own horn, I'm just trying to let y'all know that I know my sh*t, and if the lack of a foreign key causes problems in your app, the DBMS is not going to fix your problem. The problem goes much deeper.
First, Visio is *out*. Basically, it just plain sucks. All I've found it useful for is *very* rudimentary diagrams. It's so slow and cumbersome that I would never chance depending on it for a live db schema. I really wouldn't want to use it for even creating parallel docs for an existing app, it's so bad. (BTW, I have.NET for Enterprise Architects, which includes the newest Visio. Sidebar: VS.NET is great for prototyping but I wouldn't trust my reputation on an app created with it -- it's my bootstrapper.)
Second, after years upon years of experience, I've come to the conclusion that the most effective technique to use is to have a script that creates and populates the db. Tie this in with functions that do backup/restore to/from text files and you can recreate the db (schema *and* data) from any save point from pure init forward. The other advantage to this is that I despise the 'alter table' command; I find it much easier to just drop the table and then re-create and re-populate it. One key point here is that most dbs that I've dealt with (Informix, MySQL, SQL Server & Oracle) do not let you specify the default value for a new column automatically. That means you're gonna have to script the modifications to insert/compute the new column anyway. And, forget about modifying a column type, for extremely non-trivial changes it is nearly impossible (the exception being the changing of a char's or varchar's length).
And also, as a mini-rant, I have to say that the use of foreign keys has *never* been necessary in any db I've designed (and I have created very complex db apps with 30-70 well-connected tables). My point here is that your accessor logic (so-called middleware) is what manifests the "foreign" relationship and if that's screwed then your app just doesn't work. Slowing the db down to do all that referential integrity is a waste of time. You've either got the middleware right or not.
And unless you're doing hardcore statistical analysis, *never* allow nulls. If you allow nulls in *any* field, your query logic (read: the app logic itself) must be an order of mag more complex to deal with results that have nulls in their field values. Blech! Instead, disallow nulls and be careful to initialize your records properly.
This is why it is imperative to live your lives with the intent to share. Coexistent with that attitude is the idea of gratitude which ensures that those who have more than enough be thankful enough to find ways to help those who do not have enough. All this boils down to people not knowing the purpose of our existance, which is to seek God in our lifetime and do His Will. Without that wish and the further understanding that our success in fully reaching and serving God depends upon our choices, we do not have the proper perspective within our decision-making methodology to make selfless decisions. If you understand that we are tested by our Creator with gifts such as wealth, poverty, sickness and strength, then your perspective has the proper breadth.
If you think that when you die, it's all over, then you make you decisions for self, unless the selfless decision makes you feel good about yourself. That has nothing to do with making your decisions in light of our end-of-life (once the universe stops expanding) judgement and the countless (billions or trillions at least) years spent within an unaging energy body in one of the two possible destinations: heaven or hell.
What choices are you making and, more importantly, why do you approach your decision-making process as you do? Choose carefully, hell is a bad, bad place and The Deceiver of Man is ever-ready to whisper in you ear the things that will send you to accompany him in hell. He has the ability to speak in your own inner voice, making you think it is your own. That is why Muslims are blowing themselves and innocent civilians up and why priests are molesting children, amongst the other more minor tragedies of daily life, including the ridiculous obesity found in America.
Go to www.mihr.com to learn the truth and how to escape Satan and his hell. Laugh all you want, but there is no logic for *your* life choices. And certainly no big picture. And *absolutely* no real happiness (though, perhaps, pleasure).
Eh, no. The NSA basically have the best mathematicians in the world, so they knew what they were getting *way* before they bought it. And the fact that they made O(2n) dollars off their shares only further testifies to their intelligence (no pun intended).
14 years old and doing machine coding (not assembly, that's for wimps:-) on the same base architecture (minus protected mode stuff) as yer modern intel chips.
Distributed programming? How about a floppy drive that had its own ROM and RAM that you could upload programs to and execute.
I worked on two programs that eventually, through incremental development, maxed out the 48K-ish mem for the basic. One was a disk explorer, and one was a database designer that allowed me to design visual forms for data entry (for my non-existent but hopeful "black book"), complete with sorting and report output.
And lets not forget the first 3d game I ever saw/played: Star Wars, with the 3d travel down the death star groove that 'ol Luke had to go down to destroy the thing. (I think there was an arcade came of similar ilk.)
Oh, and the piracy. From languages to game disks with 10-20 games per, it was *ridiculous*. Of course, I had no money those days for anything anyway, but my friend's dad was an enthusiast and he had the connections.
14 hours straight with begrudged breaks to eat a hurried meal. Tears for Fears on the radio. And a machine code routine that pulsed the border color so quickly that it striped. How about the dog-eared copy of the "C64 Memory Map" and the volumnous disk drive reference manual. And let's never forget the beautiful simplicity of a machine code monitor.
There's a book called "Everything Important I Learned in Kindergarten". Bullshit, everything I needed I learned on my C64, then Data Structures and Algorithms in high school and college just polished it all off.
"computers, computer science, applying computer sciense to real world problems, variations of solutions depending on programming paradigm, hardware, os, or simply fashion of the current aera" is only a the limted view of a programmer:-)
I actually disagree because we are really the only people on the planet who deal with iterations in the millions and billions. Being able to deal with those numbers (and, more importantly the Butterfly Effect) gives us a better understanding of the impact of billions of human beings being senseless "in the small". They just don't realize/care that all those little wrappers add up to a big mess, and, seeing as I care for the state of the earth for my children, I'd rather proactively curb the excess from a systemic point of view *now* while it's not insoluable. That's why I turn off the light when I leave the room and why I free my heap memory as soon as it isn't needed:-)
Supposed you wanted to write a Go program.... you can be assured that memory management and flying functions and instant display of windows... are completely irrelevant.
Ah, but the performance of the meat of the algorithm *will* be *extremely* performance intensive, being the determining factor in how much look-ahead can be performed (for a brute-force method) or how many tactics can be evaluated. GC in that situation is no different than using GC in your TCP/IP stack, IMO. You've got to *squeeze* cycles out of the computer, and GC just doesn't allow that.
And, in case you don't know, I have no love for coding the same patterns over and over again, but I realize that we computer scientists are about the only craftsman who make our own tools. So, for me, the question is "what's the best tool for the job". The answer to that question probably involves many different tools, each to a specific realm, but working closely together. And my version of this toolset will generated straight machine code, God Willing:-)
Peace & Blessings, bmac www.mihr.com: if you want to know where all that dark matter & energy are
Wow! You even realized it was Kageyama's book. Man, that is strange, but cool. BTW, I didn't read the whole book because I realized that really learning Go was a full-time occupation and I already have a few of those:-) But Kage was the best writer though and I got some good info out of the few tens of pages I did read.
I hate to keep beating a dead horse, but my whole point here is the programmer should know exactly what data is no longer connected and suitably delete it immediately. And I know this is lost on the small-focused but this is indicative of our society -- we just assume someone else will take care of "it", whatever it is and no matter the the long-term costs are far greater than the short-term cost of taking care of the detail yourself. We package individual pieces of candy, and I'm nearly the only person who finds that completely ridiculous. Sure, it serves its purpose, but with a more broad- minded approach to life (and respect for future generations), we could design systems for food delivery that used 10% of the current resources. But, like I said, no one wants to inconvience themselves to improve the greater efficiency.
And I'm not gonna flame the Scheme/lisp folks, as a matter of fact I have recently begun reading said book because there are no more interesting CS books (at least at B&N, except for the DirectX & OpenGL books (and I have no time for all that fun)), so I figured that I'd trip down the Lisp lane for awhile. Anyhow, I don't see any os's written in lisp, and scant few actual programs. (Autocad, one of the finest pieces of software in the world, uses lisp for its scripting, but was written completely in C). Sure, lisp/scheme is neat for learning and "concepting" and tail-recursion is neat, but what gets the job done on a register-based processor is iterative loops, and Haskell and Lisp just don't map down better than C or even C++ (without the STL) will.
Most programmers do not even realize the power under the hood of even a Pentium II 400 (which I use). When you write straight C direct to win32 api calls, the program response is *immediate*. The program displays *instantly* and all functions *fly*. And then I load the SunOne IDE and it takes friggin one minute. Someone's missing the point here, and the person who figures out how to write bullet- proof C code for straight win32 api is going to rock some dollars.
Peace & Blessings, bmac For the fundamentals of life: www.mihr.com
Slashdot Mirror
You are one *serious* expert :-)
Anyhow, I've found that keeping hydrated has a lot to do with the amount of salt I injest as well as water. Without salt (as I figure) your body doesn't have enough sodium to retain the water -- the water just keeps on pushing through. My gauge on this is the veins in my hands; if they're flat, I'm low on both water and salt.
Anyhow, as one other dude mentioned (about some other problem), you can also keep your fluids in your body if you keep your *main* fluid in your body, IYKWIM. Vitality and surprizing looks from women are the rewards of treasuring the seed, grasshoppa -- gf or not.
Peace & Blessings,
bmac
For *all* the answers: www.mihr.com
Alec Baldwin played this bouncy guy who would help you lose weight -- by following you around and publicly beating you up. So Farley stands up (in the infomercial) and says "I'm kindof a big guy, how will you help me?" Baldwin immediately says "I'll beat you with a shovel".
Of course that's the same episode where Baldwin goes on NPR and talks about his tasty holiday treat: "Schwetty Balls".
Dang funny, that Baldwin dude.
Peace & Blessings,
bmac
For true peace & happiness: www.mihr.com
Yeah, but in *every* company I've worked for, the free coffee flowed like a flood-striken river. Screw the employees stomachs, bladders, and kidneys, make `em work faster, harder, longer. Sh*t, they would've provided crack and hydro if it was legal. Anything to get more $/t.
:-)
The important thing is that I'm not bitter
Peace & Blessings,
bmac
Check out www.mihr.com for the secrets of existence.
I wonder what effect eye color has on color sensitivity. If one has a blue iris, it must affect the "input", right? As well, there should be some sort of effect for green, gray and brown irii, right?
And, yeah, I know that the pupil is where the light goes thru, but the iris is bigger (at times) area-wise and must be letting some light thru, right? And the iris is doing some sort of "color correction" on what light makes it thru, neh?
Any ideas?
Merry Christmas, Peace & Blessings,
bmac
For lasting peace & happiness, www.mihr.com
Manual Sig Generator 4.1ish
Thanks Mr. Wall for allowing me to spend three lovely months in Helsinki, Finland. And thanks Finland, you are unbelievably beautiful.
.Sig Generator because sentiment should not be auto-generated :-)
If anyone ever gets the chance to work for/with Nokia, do it, it is a nice corporate culture and if you get to go to Finland, you will not regret it.
For you language purists, if you use a small subset of perl, you can generate very clean and even simple code. It all depends on what syntax/features you choose. And, remember, how you organize your code determines how clean the program is anyhow; the language is just the vehicle for expressing logic, the program is the destination and *how* you get there.
Peace & Blessings,
bmac
For true peace & happiness: www.mihr.com
Manual
I really don't know, but I'd guess that using harsh chemicals like those found in Clorox wipes would be bad for the monitor over long-term use.
:-)
Just a guess, but most manufacturers recommend only *mild* soap and water for such things.
But, certainly, having some damp cloth/wipes nearby would definitely help.
Peace & Blessings,
bmac
For true peace and happiness : www.mihr.com
MSG v. 4.0
Now *that's* a dang good question.
I'm drawing a blank but she'd have to be pretty young and wispy-thin.
This definitely illustrates the beauty of these books, in that the images you can create yourself will *always* surpass the reality of film.
I've listened to Gibson's Neuromancer audio book (which he, himself, read, with the Edge doing the music) well over 100 times as backnoise for programming (gotta love the subtle techno feel), and I doubt seeing a movie version, no matter how well done, will be anything but painful for me.
So this ragged train of thought begs the next question: who for Case and who for Molly? For some reason, Gary Busy (with lot's of makeup) always seems my picture of Armitage (I think he could do the "blank-as-a-button bit pretty good").
Peace & Blessings,
bmac
for true peace & happiness: www.mihr.com
Life has a purpose, if you don't know that purpose, you're already losing.
MSG 4.0
You ain't the only one.
Peace & Blessings,
bmac
www.mihr.com for true peace & happiness
I have hope that this may be added into an Extended-Edition (probably due out this time next year).
:-)
Unfortunately, I read that Jackson *never* liked that part of the books and never intended to film it, so I seriously doubt it will happen.
This really sours me on his understanding of the books as a major point of having hobbits in the first place (as far as I can gleam) is that they are going to have the need to have their own power in the 4th Age. That's another big part of Gandalf, many of the elves and the ring-bearers going across the water at the end. Sure, it's a melancholy ending, but it most of life doesn't end up all happy anyway, far as I've seen.
And hey, I said it first (AFAIK), how about making some scenes with Tom Bombadil with Patrick Stewart! I mean, the dude can sing and he kinda looks like a leprachaun which is always the picture I make of ol' Bombadil who is one of my favorite characters.
And, yeah, they fscked my *favorite* character *way* up: Faramir. But enough ranting, I didn't have the budget to make it better
Peace & Blessings,
bmac
For true peace & happiness, go to www.mihr.com
Manual Sig Generator v. 3.9ish
Just because a technology does not fully captures a requirement doesn't mean that you should avoid it entirely. You really are doing a dis-service to your client since you are not using full use of the tools they bought/implemented.
Actually, my clients are always *totally* satisfied with the results of my work, and no client I have ever worked for has given two sh*ts how I got the job done, so long as the programs worked. There are *never* any bugs in my finished product. I know it sounds ridiculous, but it's true. That's because I always use the simplest features of the chosen env and then build upon patterns that I find to work. And I test the crap out of it after every code addition.
As a further example of my disdain for the norm, I very rarely use inheritance in C++. Think that's absurd? Well, if you've read the Go4's book "Design Patterns" (truly a seminal work in CS), you would see that one of their guiding principles of oo design is "use containment over inheritance", which is where you use the parent class as a data member as opposed to as the base class. Sure, inheritance has its purpose, but you just don't use a thing because it's there, you use it for a reason after careful consideration of the other ways a purpose can be achieved and what the relative costs are. And, in my experience, FKs put into a database schema are a waste of time, whose only possible purpose would be to enhance query optimization.
Peace & Blessings,
bmac
For the secrets to life itself: www.mihr.com
MSG 3.8
Not strictly. Say you have a sales/accounting which feeds data, then you have budgeting people which needs to forcast. Say that they have two different IT departments. One uses an internal one, the other thinks that the internal is crappy and outsources. They can develop two different applications/design doc/programmer teams/end-user requirements, using the same database.
:-)
You can *not* have two different design specs implemented that *modify* the same data. Read-only apps don't count. There would be no consistent data without a consistent insert/update/delete policy. And, yes, 1000 people can read the data 1000 different ways, but that doesn't factor into the stability of the data.
Your main reason for not using them seems to be "programmers should be good enough" so they are not needed.
No, my reason for not using them is that the logic that connects those two tables (in the FK relationship) will be far more complex than just "table A has a 1:n relationship with table B". And programmers *must* be good enough to implement the level of complexity that *actually* relates the two tables, or you don't have a viable app.
It seems that you are an experienced db app developer, so I ask you: how do you set up a FK relationship between a table that has a field that, depending on another integer field, can be a link to any of N other tables? Is there a standard for this? And what if one of the integer values is for a "no link at all" condition. This real-world example demonstrates the meaningless of a FK statement (that would be required) such as "table A links to tables B, C or D via field X, depending on the value in field Y".
Peace & Blessings,
bmac
For true peace & happiness: www.mihr.com
MSG 3.85
1. Programmers make mistakes. If they were perfect you wouldn't need a whole lot of things besides FKs. But people are human. Having a data architect and a programmer work on relations is better. (two heads are better than one?) Getting messed up data is one of the worst things you can do to the reliablity of an application. You can fix a display problem or a "missing button" functionality but once that crappy data is in, its a pain to fix it, if you can.
Sure, we all make mistakes, but the really good programmers find their mistakes and fix them in the alpha stage (screw beta!).
2. FKs don't cost alot. Only in the cases of extreme number of fks.
Yeah, but anything is more than nothing, though, if, as one other poster suggested, they can improve query opt, they *would* be worth it then (but not as a reliability tool). I doubt this, though, because if my query is doing joins between indexed keys, and I've ordered my join properly, the optimizer *better* do it right, for all those thousands of dollars (excluding MySQL, of course, which, IMO, is *excellent*).
3. Helps others understand the database schema. Relational databases are not object orieniented. There is a "translation" that needs to be done from the database tables to the application objects. Just because I understand the business rules and object model doesn't mean that I understand the database model.
True, especially your last sentence, but any constraint put within a db scheme *by definition* will fall short of the truth of the relations fleshed out by the actual middleware. By definition. Proof is evident by virtue of the corollary being false: why can't all the middleware be implemented using constraints? It can't (and will never be). That's the job of functions, and documenting their purposes/effects is a thorny realm.
4. The reality is that if you are talking about a serious enterprise application, the logic for the tables might not be in one place. Either because of point 3. or because there are multiple applications accessing a singlular enterprise database.
Well, first you need to see my "2nd Law of Computer Programming" (in my journal) which states the direct relation between code organization and probability of success. Where the logic resides is irrelevant, IMO it is still just one app if it modifies the same data. Besides, there certainly isn't more than one design doc, right?
5. Programmers are hacks. Ok not all of them but some of them are. And if they see that a quick fix is to use this table in this brand new way or this field as having its own special rule, they will. This is not good because it can and will break other parts of the program or reporting. (This is an extension of point 1.)
Well, you state it yourself: it is *not good*. And no programmer of that caliber is going to work on my project. Not for long, at least. It would be a stipulation of his hiring and the grounds for his dismissal.
To sum up my feeling on FKs: they're a band-aid for a bullet wound.
Peace & Blessings,
bmac
For lasting peace & true happiness: www.mihr.com
MSG v3.6
I saw all your comments in this thread and you obvioulsy think too much of yourself. You still have to learn how fully exploit a *real* DBMS.
.sig generator v3.5 :-)
Hmm, I know what has worked for me and I *know* that my apps *never* have bugs. And that is no hyperbole. And I know that no one has *ever* written a book on how to write a bug-free app of any significant complexity. I'd love to read it, though, if/when it happens.
And, BTW, I'd really rather not come across arrogant or cocky, but text is a bad way to represent intention, and the attitude of the reader cannot be depended upon, yet it often determines how a confident opinion is interpreted. So, just for the record, my intention here is to state some beliefs my experience has ingrained and then to have content-based (as opposed to emotion-based) discussions about them. And, sure, I'm gonna fail at that last part sometimes, but I'm trying.
Ever heard something about triggers ? Or stored procedures ?
Of course I've heard of them, even tried them. But, first, I tend to not use non-standard, vendor-supplied additions to technology, especially when good ol' SQL will do the job nicely.
Technically, though, I don't use triggers because how do you error-trap an auto-exec'd fct? Sketchy at best. When will that error occur (this relates to knowing *exactly* when the trigger fct will execute). How will it get reported? If the trigger exec's before my SQL statement returns, then how do I know where the error occurred (someone here actually likes parsing SQL error statements, though I find that more error-prone then just pre-checking the failure points).
As far as stored procs go, I'd *love* to use them. To have a single list of functions be the interface to my entire persistent storage would enable an excellent interface definition. The problems are 1) that Oracle's stored proc lang is so friggin ugly that it can't be good, and 2) interfacing stored procs from a normal prog lang is too raggedy to depend on. They're just not elegant enough, and in my experience, elegance determines probability of success. And success is defined by only one thing: no bugs in a correctly coded app. Triggers and stored procs (so far) only lead to greater indeterminism and, therefore, greater chance of failure to *know* that there are no bugs.
MySQL is all fine, but prototyping in it and then porting the DB to Oracle is kind of silly IMHO.
It's not silly when the first half of the project is being written from outside a bullet-proof corporate intranet wherein the app will reside, and you have no like machine configuration to dev on. Plus, it was a challenge to seamlessly manifest the logic using manual cross-platform development techniques. It was friggin' cool, and I didn't mention that we did this with two weeks to go before my time in Finland ran out, but I still vacationed the last weekend I was there, because it was *done*.
Peace & Blessings,
bmac
Sig for me means Significant
Manual
Well, there are two ways of looking at the typical system.
.sig when you can make a new one manually each time?
I don't see it in either of the ways you mention. I see software, regardless of architecture, as made up of three interconnected realms:
1. Spacial
This is the layout of your data types. In C/OO, it's your structs, class data members, representation for enums, etc. In a RDBMS env, it's your table schemas.
2. Temporal
This is the collection of routines that modify your data structures. In an C/OO env, it's your library fcts and class member fcts. In a RDBMS it's the "middleware". In any case, this layer is the definition of how your data can change, where each change is of one of four possible types: creation, modification, deletion and selection/reading/querying. In this layer you define first how to construct a new instance of a data structure (variable or record, depending upon env) then you define the circumstances and ways it can change.
3. Visual
While this could be put under Temporal, I find it useful to break it out into its own category, mainly because I see it as being closest to your users (the Spacial being furthest away from them). In this layer all your logic resides that concerns the presentation of both data and the visual cues (like buttons) that allow the Temporal fcts to be accessed/executed. Note that the objects that will allow this layer to be built will themselves have their own spacial & temporal layers (think of the data and fctality behind a combo box).
Now, in applying this perspective to a web application, I see the database being an (obviously) spacial layer that resides in parallel with an in-memory representation of records containing table data (this parallel rep being completely dependent upon lang being used to access the db).
So, absolutely, I can see the possibility for an object-oriented auto-mapping from an OO-type of definition to a RDBMS-type of definition of the different layers. That's what a good programmer is doing mentally and organizationally if not physically (by using a tool).
And Prevaler looks to me to be just a memory RDBMS system, but I disagree with them that the db does *not* have to be stopped to dump the memory image to persistent storage. I feel that in some db apps, you would get bad results occasionally from some race conditions, which would be very difficult to track down.
Now, to my mind, nothing is going to be revolutionary in making a new language for the spacial, temporal and visual. Why? Because computers have volatile memory, permanant storage and a visual interface (even if only on the client machine). Any application you can think of is going to reside in that flow, i.e. mem to/from perm, visual to/from mem. What will be revolutionary are new ways of constructing spacial-temporal-visual frameworks (which we call applications or programs, even of the OS variety). A sufficiently advanced program could even be spacial-layer *and* temporal-layer agnostic.
Of course, as I'm writing this, it occurs to me that databases aren't so great for expressing all the constraints on the data anyhow;
Yes, because a schema definition cannot be used to define the relations defined by the temporal layer -- it's strictly spacial. A good example of this is a table that has a field that can link to different tables via the value in one of its sibling fields. This is a purely temporal relation and while it relates to the structure of the table, the actual linkage can only be described by a "links to either table A, B, or C" constraint. To put it more succinctly, relations between tables are always defined in time; on the simplest level, it's because when added joined records, one record will always be added before another.
Peace & Blessings,
bmac
For true peace & happiness, www.mihr.com
Why use a static
Though I'm not a statistician, I have done for-pay work (may years ago) using SAS and SPSS to help people analyze their data. As a result, I can tell you that NULL is used as a label for "data not present", which is used in certain stat algorithms to determine, as I understand it, a) the probability that your conclusions/results are meaningful, and b) that you have enough data to draw conclusions.
.sig generator v.4.3
If, for example, your varchar(n) field type didn't have the ability to store a null, you would have to specify (in your logic) a value for "data not present", which for some apps would not equal "". Add to that the perfect probability that some person would enter the exact string into the field that you are using for "data not here" and you can see the problem that having nulls can solve.
I've never dealt with an app that so badly needed to know that there is no data in a particular field where just initializing it to "" or 0 wouldn't work. And my point here about nulls is that for probably 99% of your modern data-centric apps that do not need hardcore stat analysis, the use of nulls is a waste of time.
Peace & Blessings,
bmac
For true peace & happiness: www.mihr.com
Manual
I hope you're trolling, and not actually deploying software.
:-)
Sorry to disappoint, but I do, and it may just happen that you end up using my software on *your* machine, someday, God Willing
This statement is analogous to "I have to say, I've never seen the use of backups to be needed on any filesystem I've worked with."
Though I'm a huge fan of hyperbole, that is an absurd analogy.
What the hell are you talking about? Quick - what's your employer's mother's sister's middle name? Hm, maybe that's a null value.
How about ""? Works for me. Empty data != null data, though one commenter noted that in Oracle (I believe) "" does actually == null. But that is absurd because null is supposed to be outside the domain of *actual* values for the field type.
I won't even begin to get in to the evil I've seen applications do to work around stupid NOT NULL declarations...
Umm, a table is a collection of data, organized into records. Each field has a range of possible values. RDBMSs allow you to give each field an optional extra value called NULL, which is a nightmare for the code that must deal with that non-value value. My apps don't "work around" the NOT NULL, they *utilize* it, to greater simplicity and, as a direct result, far greater bug-free-ness.
The default value thing I was mentioning had to do with altering a table that has data already in it. Giving the new fields in the existing records a default value has not been possible in the envs that I've worked in. This is related to another problem with adding a column after table creation, namely, that the column must be able to hold nulls, which screws up query logic, as I've found over and over.
And, as you say, most foreign key relationships are for indexed fields or groups of fields, which to my understanding would mean that that is enough information for the query optimizer to perform the query in the proper order (and let's just say that index design is where you prove where you know how to design a RDBS). I mean, no one with any clue joins on non-indexed fields, right?
And, as a matter of fact, though I design my primary keys and any secondary indexes with great care, I *do* perform the primary key checks before I ever issue an insert. Why?
*silence*
Because the insertion of a record can fail for any number of reasons: a bad key or a too-long char/varchar as two examples. Now, with two unique keys (say a primary int id and a unique name) and N string fields you have N+2 possible ways that the insert can fail. I don't like to parse db error message strings, so I perform N+2 select queries beforehand to ensure that if the insert *would* fail, I know exactly for which reason. Why? So I can tell my n00b users what they screwed up *in detail*.
And, you are most certainly correct! I do charge by the hour, because only God Himself knows how long anything is going to take, especially the successful design, understanding, implementation and testing of any halfway sophisticated piece of software. Any other pricing policy is just plain old horsesh*t. Either that or a friggin shot in the dark. My favorite formula for project estimation is: take the time you think it will take you, multiply it by three and add two.
Peace & Blessings,
bmac
I've found that subtle problems are the result of not properly designing, then incrementally building with iterim testing. And, it certainly does not take a "god" to make bug-free software, but I don't tolerate bugs in my software, because that causes my employers to have to call me, and I'd rather let them have their business logic as they want it and leave me to enjoy life.
More specifically, do you not design your software such that all your business logic for a particular table is located in the same place? How can you possibly strand a child as a result of calling a delete within that lib that calls the appropriate deletes in the child libs? If you are running an app that has stranded children you have progressed too quickly past a point where your implementation hasn't been adequately tested, neh? I mean, you have the purpose of the db in design form on some level (use-cases, formal specs, whatever...) and you implement that piece, test it with all types of parameter sets and, voila, you *know* it works. Plus, you've got the ability to generate log files for any path of logic you choose during Beta so any problems have a trace, and a proper debug trace gives you the ability to track and squash the bug, right?
On a more simple level, assuming you're a programmer, if I asked you to write a program that let the user enter strings into a list that was kept in sorted order, you could generate a program that you *knew* was correct, right? Well, with more complexity in the logic (software logic has exponential expansion, as I see it) it just takes more experience and delicacy in the development phase, where the order of implementation, care in refactoring and beligerant and relentless testing are the difference between success and being fscked.
And the DBMS can *not* manage anything because the DBMS does not spec out and implement business logic. Besides, in any sufficiently complex app, there are constraints on the values in linked tables; these type of constraints are not defineable in any db I've ever seen. As well, one can often have one field that will link to many different possible tables, depending upon values in the parent record. Perhaps that kind of constraint can be quantified in a structural definition, but, to my way of understanding it, it is more of a temporal (or dynamic) condition. Even if it could be spec'd into the schema it's no better than an assert statement (which I loathe), and certainly does not help you generate the functionality necessary to successfully construct the data.
Unfortunately, it seems that my sharing my experience is wasted on this rather abrasive crowd. I spent six months developing a monster of an ugly intranet db app for a Finnish-based international company. Up until the last two weeks we developed it using Linux and MySQL and in the last two weeks transferred it to the runtime env on Windows NT and Oracle. That was two weeks before I had to fly home from Finland, where they put me up after flying me there after the first three months. As a subcontractor, I was liable for all bugs within the project at my own expense for a year after delivery. After two months of testing, they found six bugs, all but one *very* minor. I spent eight or ten hours fixing them and then *I was done*. And this was no trifling app; it was the most aweful convoluted business logic *ever*, built with raw html and perl (not my choice).
I'm really not trying to toot my own horn, I'm just trying to let y'all know that I know my sh*t, and if the lack of a foreign key causes problems in your app, the DBMS is not going to fix your problem. The problem goes much deeper.
Peace & Blessings,
bmac
First, Visio is *out*. Basically, it just plain sucks. All I've found it useful for is *very* rudimentary diagrams. It's so slow and cumbersome that I would never chance depending on it for a live db schema. I really wouldn't want to use it for even creating parallel docs for an existing app, it's so bad. (BTW, I have .NET for Enterprise Architects, which includes the newest Visio. Sidebar: VS.NET is great for prototyping but I wouldn't trust my reputation on an app created with it -- it's my bootstrapper.)
Second, after years upon years of experience, I've come to the conclusion that the most effective technique to use is to have a script that creates and populates the db. Tie this in with functions that do backup/restore to/from text files and you can recreate the db (schema *and* data) from any save point from pure init forward. The other advantage to this is that I despise the 'alter table' command; I find it much easier to just drop the table and then re-create and re-populate it. One key point here is that most dbs that I've dealt with (Informix, MySQL, SQL Server & Oracle) do not let you specify the default value for a new column automatically. That means you're gonna have to script the modifications to insert/compute the new column anyway. And, forget about modifying a column type, for extremely non-trivial changes it is nearly impossible (the exception being the changing of a char's or varchar's length).
And also, as a mini-rant, I have to say that the use of foreign keys has *never* been necessary in any db I've designed (and I have created very complex db apps with 30-70 well-connected tables). My point here is that your accessor logic (so-called middleware) is what manifests the "foreign" relationship and if that's screwed then your app just doesn't work. Slowing the db down to do all that referential integrity is a waste of time. You've either got the middleware right or not.
And unless you're doing hardcore statistical analysis, *never* allow nulls. If you allow nulls in *any* field, your query logic (read: the app logic itself) must be an order of mag more complex to deal with results that have nulls in their field values. Blech! Instead, disallow nulls and be careful to initialize your records properly.
Good luck.
Peace & Blessings,
bmac
For true peace & happiness: www.mihr.com
This is why it is imperative to live your lives with the intent to share. Coexistent with that attitude is the idea of gratitude which ensures that those who have more than enough be thankful enough to find ways to help those who do not have enough. All this boils down to people not knowing the purpose of our existance, which is to seek God in our lifetime and do His Will. Without that wish and the further understanding that our success in fully reaching and serving God depends upon our choices, we do not have the proper perspective within our decision-making methodology to make selfless decisions. If you understand that we are tested by our Creator with gifts such as wealth, poverty, sickness and strength, then your perspective has the proper breadth.
If you think that when you die, it's all over, then you make you decisions for self, unless the selfless decision makes you feel good about yourself. That has nothing to do with making your decisions in light of our end-of-life (once the universe stops expanding) judgement and the countless (billions or trillions at least) years spent within an unaging energy body in one of the two possible destinations: heaven or hell.
What choices are you making and, more importantly, why do you approach your decision-making process as you do? Choose carefully, hell is a bad, bad place and The Deceiver of Man is ever-ready to whisper in you ear the things that will send you to accompany him in hell. He has the ability to speak in your own inner voice, making you think it is your own. That is why Muslims are blowing themselves and innocent civilians up and why priests are molesting children, amongst the other more minor tragedies of daily life, including the ridiculous obesity found in America.
Go to www.mihr.com to learn the truth and how to escape Satan and his hell. Laugh all you want, but there is no logic for *your* life choices. And certainly no big picture. And *absolutely* no real happiness (though, perhaps, pleasure).
Peace & Blessings
bmac
but that's the best damn troll I've
ever read.
Peace & Blessings,
bmac
Eh, no. The NSA basically have the best
mathematicians in the world, so they
knew what they were getting *way* before
they bought it. And the fact that they
made O(2n) dollars off their shares only
further testifies to their intelligence
(no pun intended).
-bmac
14 years old and doing machine coding (not assembly, that's for wimps :-) on the same base architecture (minus protected mode stuff) as yer modern intel chips.
Distributed programming? How about a floppy drive that had its own ROM and RAM that you could upload programs to and execute.
I worked on two programs that eventually, through incremental development, maxed out the 48K-ish mem for the basic. One was a disk explorer, and one was a database designer that allowed me to design visual forms for data entry (for my non-existent but hopeful "black book"), complete with sorting and report output.
And lets not forget the first 3d game I ever saw/played: Star Wars, with the 3d travel down the death star groove that 'ol Luke had to go down to destroy the thing. (I think there was an arcade came of similar ilk.)
Oh, and the piracy. From languages to game disks with 10-20 games per, it was *ridiculous*. Of course, I had no money those days for anything anyway, but my friend's dad was an enthusiast and he had the connections.
14 hours straight with begrudged breaks to eat a hurried meal. Tears for Fears on the radio. And a machine code routine that pulsed the border color so quickly that it striped. How about the dog-eared copy of the "C64 Memory Map" and the volumnous disk drive reference manual. And let's never forget the beautiful simplicity of a machine code monitor.
There's a book called "Everything Important I Learned in Kindergarten". Bullshit, everything I needed I learned on my C64, then Data Structures and Algorithms in high school and college just polished it all off.
Thanks Commodore! You rocked.
"computers, computer science, applying computer sciense to real world problems, variations of solutions depending on programming paradigm, hardware, os, or simply fashion of the current aera" is only a the limted view of a programmer :-)
:-)
.... you can be assured that memory management and flying functions and instant display of windows ... are completely irrelevant.
:-)
I actually disagree because we are really
the only people on the planet who deal with
iterations in the millions and billions. Being
able to deal with those numbers (and, more
importantly the Butterfly Effect) gives us a
better understanding of the impact of billions
of human beings being senseless "in the small".
They just don't realize/care that all those
little wrappers add up to a big mess, and,
seeing as I care for the state of the earth
for my children, I'd rather proactively curb
the excess from a systemic point of view
*now* while it's not insoluable. That's why
I turn off the light when I leave the room
and why I free my heap memory as soon as it
isn't needed
Supposed you wanted to write a Go program
Ah, but the performance of the meat of the
algorithm *will* be *extremely* performance
intensive, being the determining factor in
how much look-ahead can be performed (for a
brute-force method) or how many tactics
can be evaluated. GC in that situation is
no different than using GC in your TCP/IP
stack, IMO. You've got to *squeeze* cycles
out of the computer, and GC just doesn't
allow that.
And, in case you don't know, I have no
love for coding the same patterns over and
over again, but I realize that we computer
scientists are about the only craftsman who
make our own tools. So, for me, the question
is "what's the best tool for the job". The
answer to that question probably involves
many different tools, each to a specific realm,
but working closely together. And my version
of this toolset will generated straight machine
code, God Willing
Peace & Blessings,
bmac
www.mihr.com: if you want to know where all
that dark matter & energy are
Wow! You even realized it was Kageyama's :-) But Kage was the best
book. Man, that is strange, but cool.
BTW, I didn't read the whole book because
I realized that really learning Go was a
full-time occupation and I already have a
few of those
writer though and I got some good info out
of the few tens of pages I did read.
I hate to keep beating a dead horse, but
my whole point here is the programmer
should know exactly what data is no longer
connected and suitably delete it immediately.
And I know this is lost on the small-focused
but this is indicative of our society -- we
just assume someone else will take care of
"it", whatever it is and no matter the the
long-term costs are far greater than the
short-term cost of taking care of the detail
yourself. We package individual pieces of
candy, and I'm nearly the only person who
finds that completely ridiculous. Sure, it
serves its purpose, but with a more broad-
minded approach to life (and respect for
future generations), we could design systems
for food delivery that used 10% of the current
resources. But, like I said, no one wants
to inconvience themselves to improve the
greater efficiency.
And I'm not gonna flame the Scheme/lisp folks,
as a matter of fact I have recently begun
reading said book because there are no more
interesting CS books (at least at B&N, except
for the DirectX & OpenGL books (and I have
no time for all that fun)), so I figured that
I'd trip down the Lisp lane for awhile.
Anyhow, I don't see any os's written in lisp,
and scant few actual programs. (Autocad, one
of the finest pieces of software in the world,
uses lisp for its scripting, but was written
completely in C). Sure, lisp/scheme is neat
for learning and "concepting" and tail-recursion
is neat, but what gets the job done on a
register-based processor is iterative loops,
and Haskell and Lisp just don't map down
better than C or even C++ (without the STL)
will.
Most programmers do not even realize the power
under the hood of even a Pentium II 400 (which
I use). When you write straight C direct to
win32 api calls, the program response is
*immediate*. The program displays *instantly*
and all functions *fly*. And then I load
the SunOne IDE and it takes friggin one
minute. Someone's missing the point here, and
the person who figures out how to write bullet-
proof C code for straight win32 api is going
to rock some dollars.
Peace & Blessings,
bmac
For the fundamentals of life: www.mihr.com