Oh but that's right, there's that whole field of innovative sports games that all look the same (except the hockey net is replaced with an upright goal post, and the "ice" changes to a football field.
Yeah, I got so pissed off yesterday when playing Madden that I got called for a two-line pass that my Xbox also gave me a technical foul.
Thankfully, I managed to pull out the victory in extra innings. It was the World Cup Finals, after all.
A database that is perfectly "well-factored", lacking in redundancy and providing complete consistency -- but runs like a dead pig in molasses is not a well-designed database, because it does not meet the often implicit requirement to perform at a given throughput.
I say that if you do database design without considering the performance impacts, you're not doing database design in the real world. At that point, it's an academic problem. If you're attempting to solve an actual problem or build an actual system, you must consider the performance nature and limitations of the database every bit as much as a civil or structural engineer must understand the difference between suspension and piling bridges.
The very fact that you refer to domains means you're somewhat familiar with logical modeling, but the difference between logical modeling and physical modeling is significantly greater than switching the view in ERwin. Hell, the flexibility toward future needs is an implementation specific issue, because with some RDBMS's you can add, remove, and change columns under some circumstances, and in others you cannot.
Regrettably, academia does not focus on these differences, so we tend to get perfectly elegant designs -- that don't work, and it's all the DB designer's fault. Better tools that take into account the questions I raised to make design more interactive may help, but often those questions aren't and can't be addressed before a system runs into customers.
Codd's terse, but the theory is complete. It's written in an academic style with the assumption of a great many fundamentals.
Hell, DB2 didn't have sequences until version 8. Of course, one can semi-implement them in databases which don't support sequences by:
Create a table with a single IDENTITY/AUTOINCREMENT column.
Instead of fetching from a sequence, do an insert into this table, then select using whatever your system is for getting an IDENTITY/AUTOINCREMENT column back. Delete the row when done to prevent you from having a giant table of sequential values.
When you want to reset the sequence, drop and recreate the tables.
However, this is slashdot, where open-source is good and proprietary is bad. Therefore, a novice will see that MySQL and Oracle are both databases, but one's open-source, so MySQL must be better for their critical data and systems.
Whoops.
SAP probably still sells more systems that run against Oracle and DB2 than against MySQL. Further, let's not hold up SAP as a shining example of openness -- unless you've ever supported it, you do not know the horrors that lie within. If you ever wanted to see a fascist company from a support perspective (oh, you didn't follow our recommendations? No support for you!)
MySQL is an excellent alternative to Access or as a simple backend for data without ACID or sophisticated design.
To use an analogy, it's a garden trowel. Use it to dig up your flower box. However, it's not the right tool to till or cultivate a cornfield.
Also, I've read that joins is generally more efficient than doing subqueries.
It depends on how restrictive the subquery is -- for example, if a subquery of a 1,000,000 row table returns 10 rows and you're joining it to another 1,000,000 row table (or to itself), then the subquery will likely be more efficient than a simple join, especially if the order in which the predicates are evaluated is tricky -- is the join predicate evaluated before the data restriction predicate?
If everything else fails, use temporary tables.
Provided, of course, that you've got the disk space, fast enough disk, and things like concurrency and data integrity are of secondary importance.
Database design should be a generic RDBMS book for the most part.
I wish I could explain just how incorrect and incomplete your statement is.
A few questions to demonstrate:
You've got a financial application where you want to see account balances as they change in real time. How do you do it so that performance of both update (for the transactions coming in) and select (for the users of the application) performance will scale linearly if not logarithmically as the number of transactions increases? For which RDBMS?
You've got a table with CHAR, VARCHAR, NUMBER, and DATE columns. Some columns are updated often, some are updated never. What should the physical order of the column be, and why? For which RDBMS?
What's the impact of table partitioning for various types of partitioning, such as hash (round robin of rows), list (specific discrete values correspond to different partitions), and range (values between x and y-1 are in one partition, values between y and z-1 are in another partition). How does it impact performance? How does it impact scalability? How does it impact manageability? Which vendors support which partitioning schemes? Why does it matter how you tend to access your data important when determining how to partition? How can partitioning inhibit performance?
What's the impact of issuing an update versus issuing a delete and then an insert?
What's the impact of using triggers to enforce RI versus using database constraints? Which systems support which methods?
If you want the generic theory of database design, read Codd. If you're not interested in scalability or integrity, use Access or MySQL, and you'll be fine.
If you want to build mission-critical systems, the choice of platform must direct your design decisions, and if you ignore that, you will paint yourself into a corner.
You don't need vendor-specific tips -- you need vendor-specific books, such as Tom Kyte's _Effective Oracle by Design_, or Yevich and Lawson's _DB2 High Performance Design and Tuning_.
Hmmm... Let's see what would describe the Windows of SQL DBMSes... what would be the criteria... Well, it would have to be
Proprietary Attempt to use closed technologies to lock in users Add useless, heavy features that impact routine tasks and stability Be very expensive Have executive management that seeks to dominate the market through manipulation of sales channels You're right about one thing... there is an RDBMS that fits your description, but I'm afraid it's not MySQL.
I'm assuming that is is something of a shot at Oracle, and to some degree it's justified.
However, some of what I perceive you to be calling negatives are not necessarily so --
Proprietary: As RDBMS's are generally considered strategic or enterprise software, and are relied upon by virtually every business not run from a garage to ensure data access, consistency, and recoverability.
Until recently (in business time), Linux (and other open source OS's) were considered toys, not ready for mission-critical applications. People didn't trust it in the data center unless, frankly, they knew they could get someone to talk to in real time if things went bad, and someone they could sue if things got really bad.
However, to my knowledge, there's been no enterprise-class open-source database with a support organization that can be available 24x7 until very recently. Perhaps MySQL will get there -- perhaps it won't. Perhaps someone else will reverse-engineer Oracle, or Sybase, or SQL Server, or DB2, or Informix, and there'll a clean-room implementation that could be used to more directly compete with the established vendors.
Attempt to use closed technologies to lock in users: You call this a bad thing -- I call it coding to the bare metal. Heck, don't things get added to the SQL standard by looking at what's been implemented? People rarely change the RDBMS for a mission-critical system, because there's definite risk of data loss and corruption by migrating the data (also, there's the fact that you tend to need downtime to do so).
Cost: Cost is a relative thing. Mission-critical software could conceivably be free, but mission-critical support never will be, because gurus who can fix your severity 1 problem at 4 am and how can jump on a plane to go to your data center will never be cheap. Accept that as the cost of doing business, because it is.
Useless, heavy features: I don't agree that an RDBMS should be an a la carte roll-your-own system. It's a system -- there's meaning to the word -- and the interdependencies required for a smaller code base can get nasty. Besides, I know with Oracle lots of features are optional, and don't have to be purchased, and some you get for free don't need to be installed.
Management: This is slashdot. Name a technology company executive (or any sales organization) who is not reviled. Larry Ellison is a whole pile of neuroses and wants to be King of the World, but at least he's not trying to get there primarily through litigation (DoJ suit regarding PeopleSoft merger was a response to DoJ's recommendation, not a stickup) or through extension of a de facto monopoly
I, personally, feel your comments are more damning to SQL Server (pick you OS, so long as it's ours) and DB2 (3 RDMBS, all with the same name, all who do things differently depending on the OS). None are perfect -- if one were, we'd all use it, and then it'd be broken into several companies all of which would go their own direction.
I completely agree. SQL agnosticism is orthogonal to performance without some truly torturous coding, if not complete code forking.
Different databases handle all sorts of thing differently, like:
Transaction consisentency Locking (specifically, granularity and escalation) Logging Undo mechanism RI mechanisms (triggers, constraints, deferrability, reliance)
Some databases (DB2) are designed for lots of small, short, targeted transactions. Some databases (Oracle) are designed for large, long, complicated transactions. Some databases don't seem to understand the concepts of transactions, at least not from an ACID perspective.
The only time you should concern yourself with database/SQL agnosticism is if you are working on a COTS product, as I am. If you're working on a hobby or internal project, utilize the full feature set of the database! You wouldn't not fully use $SCRIPTING_LANGUAGE because $SCRIPTING_ALTERNATE didn't support a feature cleanly. How often does a production app get migrated to a new OS architecture, like from Unix to Windows, or Risc to X86? Not often. But we pretend that we're going to potentially migrate an app from $RDBMS to $RDBMS, and I've never seen such a process work.
Most people pay big money for a sophisticated piece of software, and pretend it's nothing more than a file system or VSAM, and that's a colossal waste of time, money, and people.
I know that databases have column level permissions, but what I really needed was *row* permissions -- the supplier's database account would only have permissions to SELECT rows that had a particular supplier_id.
Oracle supports this through a mechanism called Fine-Grained Access Control. Your users, on logging in, can be assigned to one or more Security Policy Groups. These Security Policy Groups can each have one or more predicates for various tables in the application which are automatically applied.
The advantage to this is that even if your users have direct SQL access to your system, a login trigger can accomplish the assignment to a security policy group, and you can create stored procedures which would allow them to change their security policy group (if that's the sort of thing you wanted to do).
So in your example, User X who works for Supplier 100 would be restricted to Supplier 100's data by setting the Security Policy to Supplier = 100. Then every query against the table(s) specified would have the predicate " and supplier_id = 100'. The database would prevent access to any other supplier's data. If user X changes companies and now works for Supplier 101, change him to be a member of a different security policy group, and he can no longer see supplier 100's data.
Oh, you wanted this in MySQL? No idea.
I'd imagine that you could to enforce such a thing through application logic, and as a DBA, if there's one thing I'm disinclined to trust, it's that the application will correctly and completely implement concepts like security and relational integrity. As the database is the point source for data access, it should be the point source for data security and data consistency.
Your mileage may vary, but the list price of Oracle is now significantly more reasonable than in the past (list price of $5k per proc if running on a 2-way machine).
Where did I get the idea that humans should never commit acts of violence? If I accept your hypothesis that "violence is never necessary", then humans should never commit acts of violence. Further, should they do so, their choice is ultimately one of selfishness or one of futility, but never one borne out of nobility.
I will not indict those who choose not to act violently. However, to assume that a violent response cannot be justified by an enlighted person is to capitulate to any threat, to be unwilling to sacrifice for others, to become adrift in the sea of morality.
Two hypothetical examples:
Would you defend the lives of your signifiant other and any children you may have against the forces of nature, possibly sacrificing your life to save them?
Would you defned the lives of your significant other and any children you may have against the forces of fascism and oppressions, possibly sacrificing your life to save them?
If the answer to the first is yes and the answer to the second is no, I ask you to recall that nature, red in tooth and claw, lacks moral or ethical imperatives. Mankind does not, and therefore those actions of man which violate moral and ethical imperatives should be resisted as strongly, if not more so.
You can argue that there is no good or evil in this world, or in any other. However, the vast majority of humanity does not share that nihilistic viewpoint, and their disagreement with your perspective does not render their position irrelevant. (Calling your opposition polarized and adolescent is generally not the best way to conduct reasoned discourse, as you do not demonstrate respect for opposing viewpoints, only contempt.) Good and evil are convenient labels, perhaps too convenient. A simpler one is "us vs them," but that fails to indicate whether one believes one's actions are ethical and moral.
I agree that hope can prevent violence -- however, hope cannot preclude violence. At some point, there is a choice each of us will make regarding what we hold dear, and whether we hold that dearer than our very life.
I completely disagree that violence is never necessary, because the human condition is full of gray areas, and I've not experienced a truly always or never truth. Humans are way too unpredictable to say what they will always or never do -- provided the laws of physics aren't violated, there seems to be no triumph and no evil we are not capable of.
I'm sure you've heard the saying that all that is necessary for evil to triumph is for good men to do nothing. Do you not believe that to be true? Do you believe that wishing and hoping can prevent atrocity and oppression?
Then I imagine you would willingly all of your worldly possessions and promise to obey every instruction of the first person to threaten violence unto you. I guess the first mugger who ever asks for your wallet is in for a real treat.
Oh, wait, violence is only necessary provided humans act nobly in all cases.
The futility you so blithely refer to is what we like to call the human condition. I certainly hope you get used to the fact that it does not live up to your expectations before you do something rash.
You may wish to illuminate the futility of either option; however, if there is nothing in this world, spiritual, personal, or material worth dying for, then there is nothing of worth in this world.
It's he, you may recall, whose one-sided political hatched job on Steve Forbes (referring to the flat tax as a "wacky scheme" in a straight news piece) convinced Bernard Goldberg to expose the MSM medias biases for what they are. Such exposure cost Bernard Goldberg the number 2 spot at CBS news and likely the anchor desk once someone pries it from Dan Rather's cold, dead hands.
Apparently journalism that states its biases and doesn't use codewords like "senior Administration officials" isn't journalism -- it's better, and we can't be having that.
The way I read the treaty is that so long as the orbital or deep space military installations do not utilize weapons of mass destruction, then they are not prohibited by treaty. Weapons of conventional destruction (such as kamikaze or focused microwave killersats) are unfriendly, but not prohibited. Even a cloud-to-ground tactical strike capability a la "the finger of $DEITY" would not be prohibited unless it utilized weapons of mass destruction.
Your mileage may vary.
If we posit that supporting weapons of mass destruction systems would also violate the treaty, well, then GPS violates it was well, as that can be used for tactical nuclear delivery systems (namely, finding where one is shooting from).
Precisely. The planning of the ability to exert space superiority does not violate the treaty. Possession of the means to exercise space superiority (or space denial, if you prefer) does not violate the treaty. Only if and only if USSpaceCom places weapons of mass destruction (nuclear, chemical, or biological according to the US definitions) in orbit or beyond is the US in violation...
And conventional munitions are so very much more America's style. Sure, the occasional FAE munition is of use (for things like clearing a division-sized hole in the lines), but most of the time the United States military is concerned about putting ordnance on target, not scattering the rubble farther and wider. Killersats with the ability to preemptively strike other orbiting objects are completely legal -- and necessary, when one considers the signal and observation intelligence one can obtain through satellites.
Angelina Jolie will only play Honor Harrington in any media if and only if authorized by David Weber's estate (read: over his dead body), and I would not be surprised if he had a codicil in his will preventing such.
(For those who don't know, Angelina Jolie was able to adopt a Cambodian child in unbelievably expedited fashion while the Weber's adoption -- and seemingly everyone else who wasn't famous --was placed on bureaucratic hold.)
I'm stepping out on a limb here, but I think you will end up having to lock all tables to make a real consistent backup of your database where all tables relational data is gauranteed intact.
A thought experiment to demonstrate why this is incorrect, with the postulate we are not working at a quantum level:
Imagine a particle x.
If you know the exact location of this particle at some time t(0), and you know completely every vector constituting its movement until time tn....
Can you describe the exact location of particle X at time t(n), or at any time in between?
Modern, robust, ACID-compliant (and expensive) database systems use exactly this type of system to take read-consistent backups. All Oracle does is defer writes to a tablespace in backup mode to ensure all changes have been written as of the System Change Number (time t(0) in the above example) in the header file for every data file in the tablespace.
Heck, with those change vectors (as well as the rollback information), Oracle can tell allow you to *query* the database as of a given time. (within limitations, of course).
Actually, right field is not the place in baseball where the "lupus" plays once progressing past Little League, as the right fielder generally must be a more competent fielder and thrower to mitigate the number of first-to-third opportunities.
Well, when working on a COTS product, vendor lock-in is a real problem.
Until, of course, you abstract all the database access to views to hide from the user the native calls required (like join syntax, and date conversion, and the like).
ORA92:select count(*) from t1
2 where vc2_col is null
3 and vc_col is null
4 and char_col is null;
COUNT(*) ----------
1
ORA92:select * from v$version
2/
BANNER Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production PL/SQL Release 9.2.0.3.0 - Production CORE 9.2.0.3.0 Production TNS for Solaris: Version 9.2.0.3.0 - Production NLSRTL Version 9.2.0.3.0 - Production
The problem with NULL is that you don't know what it means. Suppose you have a field 'Job' in a table 'Persons'. When it's not NULL, you know that person has a job. But when it is NULL, it could mean: -this person has no job; -the job of this person is unknown.
Then the problem is in your relational model. You need a record in the Job table akin to "No job." If the person has no job, link the job field in the person record to the "no job" record in the Job table. If there is no data regarding the job of that person (for example, no input data was provided), then NULL is completely correct.
Alternatively, you could set up the appropriate "indeterminate job" records in your job table and your question becomes much, much simpler. Of course, then you have to know exactly which indeterminate states you're looking for -- no data provided, invalid data provided, job person had was eliminated, and the like.
This would be a solution you'd probably use if the reason for the indeterminate nature of the state were relevant -- if your application doesn't care why the state is irrelevant, don't bother trying to map the reason and go with the NULL.
The value of NULL is that it means what it means -- namely, and indeterminate state. If you "know" someone has no job, using NULL is incorrect -- link the Person to the "no job" Job record.
If I remember correctly, this "maintenance" was a monthly reboot which was necessary because the software (in this case Windows) would fail without it. You can blame that on poor management, poor training, lack of diligence, or faulty software.
Of course, that'd never happen without windows, like with the Solaris Uptime Bug, where you might have to reboot your Solaris server every 24 days.
http://sunportal.sunmanagers.org/pipermail/summa ri es/2002-June/001844.html
Let's not pretend that Windows is the only tool in the shed that can be used to build a fragile system.
Slashdot Mirror
Yeah, I got so pissed off yesterday when playing Madden that I got called for a two-line pass that my Xbox also gave me a technical foul.
Thankfully, I managed to pull out the victory in extra innings. It was the World Cup Finals, after all.
A database that is perfectly "well-factored", lacking in redundancy and providing complete consistency -- but runs like a dead pig in molasses is not a well-designed database, because it does not meet the often implicit requirement to perform at a given throughput.
I say that if you do database design without considering the performance impacts, you're not doing database design in the real world. At that point, it's an academic problem. If you're attempting to solve an actual problem or build an actual system, you must consider the performance nature and limitations of the database every bit as much as a civil or structural engineer must understand the difference between suspension and piling bridges.
The very fact that you refer to domains means you're somewhat familiar with logical modeling, but the difference between logical modeling and physical modeling is significantly greater than switching the view in ERwin. Hell, the flexibility toward future needs is an implementation specific issue, because with some RDBMS's you can add, remove, and change columns under some circumstances, and in others you cannot.
Regrettably, academia does not focus on these differences, so we tend to get perfectly elegant designs -- that don't work, and it's all the DB designer's fault. Better tools that take into account the questions I raised to make design more interactive may help, but often those questions aren't and can't be addressed before a system runs into customers.
Codd's terse, but the theory is complete. It's written in an academic style with the assumption of a great many fundamentals.
Hell, DB2 didn't have sequences until version 8. Of course, one can semi-implement them in databases which don't support sequences by:
Create a table with a single IDENTITY/AUTOINCREMENT column.
Instead of fetching from a sequence, do an insert into this table, then select using whatever your system is for getting an IDENTITY/AUTOINCREMENT column back. Delete the row when done to prevent you from having a giant table of sequential values.
When you want to reset the sequence, drop and recreate the tables.
However, this is slashdot, where open-source is good and proprietary is bad. Therefore, a novice will see that MySQL and Oracle are both databases, but one's open-source, so MySQL must be better for their critical data and systems.
Whoops.
SAP probably still sells more systems that run against Oracle and DB2 than against MySQL. Further, let's not hold up SAP as a shining example of openness -- unless you've ever supported it, you do not know the horrors that lie within. If you ever wanted to see a fascist company from a support perspective (oh, you didn't follow our recommendations? No support for you!)
MySQL is an excellent alternative to Access or as a simple backend for data without ACID or sophisticated design.
To use an analogy, it's a garden trowel. Use it to dig up your flower box. However, it's not the right tool to till or cultivate a cornfield.
I wish I could explain just how incorrect and incomplete your statement is.
A few questions to demonstrate:
You've got a financial application where you want to see account balances as they change in real time. How do you do it so that performance of both update (for the transactions coming in) and select (for the users of the application) performance will scale linearly if not logarithmically as the number of transactions increases? For which RDBMS?
You've got a table with CHAR, VARCHAR, NUMBER, and DATE columns. Some columns are updated often, some are updated never. What should the physical order of the column be, and why? For which RDBMS?
What's the impact of table partitioning for various types of partitioning, such as hash (round robin of rows), list (specific discrete values correspond to different partitions), and range (values between x and y-1 are in one partition, values between y and z-1 are in another partition). How does it impact performance? How does it impact scalability? How does it impact manageability? Which vendors support which partitioning schemes? Why does it matter how you tend to access your data important when determining how to partition? How can partitioning inhibit performance?
What's the impact of issuing an update versus issuing a delete and then an insert?
What's the impact of using triggers to enforce RI versus using database constraints? Which systems support which methods?
If you want the generic theory of database design, read Codd. If you're not interested in scalability or integrity, use Access or MySQL, and you'll be fine.
If you want to build mission-critical systems, the choice of platform must direct your design decisions, and if you ignore that, you will paint yourself into a corner.
You don't need vendor-specific tips -- you need vendor-specific books, such as Tom Kyte's _Effective Oracle by Design_, or Yevich and Lawson's _DB2 High Performance Design and Tuning_.
I'm assuming that is is something of a shot at Oracle, and to some degree it's justified.
However, some of what I perceive you to be calling negatives are not necessarily so --
Proprietary: As RDBMS's are generally considered strategic or enterprise software, and are relied upon by virtually every business not run from a garage to ensure data access, consistency, and recoverability.
Until recently (in business time), Linux (and other open source OS's) were considered toys, not ready for mission-critical applications. People didn't trust it in the data center unless, frankly, they knew they could get someone to talk to in real time if things went bad, and someone they could sue if things got really bad.
However, to my knowledge, there's been no enterprise-class open-source database with a support organization that can be available 24x7 until very recently. Perhaps MySQL will get there -- perhaps it won't. Perhaps someone else will reverse-engineer Oracle, or Sybase, or SQL Server, or DB2, or Informix, and there'll a clean-room implementation that could be used to more directly compete with the established vendors.
Attempt to use closed technologies to lock in users: You call this a bad thing -- I call it coding to the bare metal. Heck, don't things get added to the SQL standard by looking at what's been implemented? People rarely change the RDBMS for a mission-critical system, because there's definite risk of data loss and corruption by migrating the data (also, there's the fact that you tend to need downtime to do so).
Cost: Cost is a relative thing. Mission-critical software could conceivably be free, but mission-critical support never will be, because gurus who can fix your severity 1 problem at 4 am and how can jump on a plane to go to your data center will never be cheap. Accept that as the cost of doing business, because it is.
Useless, heavy features: I don't agree that an RDBMS should be an a la carte roll-your-own system. It's a system -- there's meaning to the word -- and the interdependencies required for a smaller code base can get nasty. Besides, I know with Oracle lots of features are optional, and don't have to be purchased, and some you get for free don't need to be installed.
Management: This is slashdot. Name a technology company executive (or any sales organization) who is not reviled. Larry Ellison is a whole pile of neuroses and wants to be King of the World, but at least he's not trying to get there primarily through litigation (DoJ suit regarding PeopleSoft merger was a response to DoJ's recommendation, not a stickup) or through extension of a de facto monopoly
I, personally, feel your comments are more damning to SQL Server (pick you OS, so long as it's ours) and DB2 (3 RDMBS, all with the same name, all who do things differently depending on the OS). None are perfect -- if one were, we'd all use it, and then it'd be broken into several companies all of which would go their own direction.
I completely agree. SQL agnosticism is orthogonal to performance without some truly torturous coding, if not complete code forking.
Different databases handle all sorts of thing differently, like:
Transaction consisentency
Locking (specifically, granularity and escalation)
Logging
Undo mechanism
RI mechanisms (triggers, constraints, deferrability, reliance)
Some databases (DB2) are designed for lots of small, short, targeted transactions. Some databases (Oracle) are designed for large, long, complicated transactions. Some databases don't seem to understand the concepts of transactions, at least not from an ACID perspective.
The only time you should concern yourself with database/SQL agnosticism is if you are working on a COTS product, as I am. If you're working on a hobby or internal project, utilize the full feature set of the database! You wouldn't not fully use $SCRIPTING_LANGUAGE because $SCRIPTING_ALTERNATE didn't support a feature cleanly. How often does a production app get migrated to a new OS architecture, like from Unix to Windows, or Risc to X86? Not often. But we pretend that we're going to potentially migrate an app from $RDBMS to $RDBMS, and I've never seen such a process work.
Most people pay big money for a sophisticated piece of software, and pretend it's nothing more than a file system or VSAM, and that's a colossal waste of time, money, and people.
Oracle supports this through a mechanism called Fine-Grained Access Control. Your users, on logging in, can be assigned to one or more Security Policy Groups. These Security Policy Groups can each have one or more predicates for various tables in the application which are automatically applied.
The advantage to this is that even if your users have direct SQL access to your system, a login trigger can accomplish the assignment to a security policy group, and you can create stored procedures which would allow them to change their security policy group (if that's the sort of thing you wanted to do).
So in your example, User X who works for Supplier 100 would be restricted to Supplier 100's data by setting the Security Policy to Supplier = 100. Then every query against the table(s) specified would have the predicate " and supplier_id = 100'. The database would prevent access to any other supplier's data. If user X changes companies and now works for Supplier 101, change him to be a member of a different security policy group, and he can no longer see supplier 100's data.
Oh, you wanted this in MySQL? No idea.
I'd imagine that you could to enforce such a thing through application logic, and as a DBA, if there's one thing I'm disinclined to trust, it's that the application will correctly and completely implement concepts like security and relational integrity. As the database is the point source for data access, it should be the point source for data security and data consistency.
Your mileage may vary, but the list price of Oracle is now significantly more reasonable than in the past (list price of $5k per proc if running on a 2-way machine).
Where did I get the idea that humans should never commit acts of violence? If I accept your hypothesis that "violence is never necessary", then humans should never commit acts of violence. Further, should they do so, their choice is ultimately one of selfishness or one of futility, but never one borne out of nobility.
I will not indict those who choose not to act violently. However, to assume that a violent response cannot be justified by an enlighted person is to capitulate to any threat, to be unwilling to sacrifice for others, to become adrift in the sea of morality.
Two hypothetical examples:
Would you defend the lives of your signifiant other and any children you may have against the forces of nature, possibly sacrificing your life to save them?
Would you defned the lives of your significant other and any children you may have against the forces of fascism and oppressions, possibly sacrificing your life to save them?
If the answer to the first is yes and the answer to the second is no, I ask you to recall that nature, red in tooth and claw, lacks moral or ethical imperatives. Mankind does not, and therefore those actions of man which violate moral and ethical imperatives should be resisted as strongly, if not more so.
You can argue that there is no good or evil in this world, or in any other. However, the vast majority of humanity does not share that nihilistic viewpoint, and their disagreement with your perspective does not render their position irrelevant. (Calling your opposition polarized and adolescent is generally not the best way to conduct reasoned discourse, as you do not demonstrate respect for opposing viewpoints, only contempt.) Good and evil are convenient labels, perhaps too convenient. A simpler one is "us vs them," but that fails to indicate whether one believes one's actions are ethical and moral.
I agree that hope can prevent violence -- however, hope cannot preclude violence. At some point, there is a choice each of us will make regarding what we hold dear, and whether we hold that dearer than our very life.
I completely disagree that violence is never necessary, because the human condition is full of gray areas, and I've not experienced a truly always or never truth. Humans are way too unpredictable to say what they will always or never do -- provided the laws of physics aren't violated, there seems to be no triumph and no evil we are not capable of.
I'm sure you've heard the saying that all that is necessary for evil to triumph is for good men to do nothing. Do you not believe that to be true? Do you believe that wishing and hoping can prevent atrocity and oppression?
The only thing worth dying for is life itself?
Then I imagine you would willingly all of your worldly possessions and promise to obey every instruction of the first person to threaten violence unto you. I guess the first mugger who ever asks for your wallet is in for a real treat.
Oh, wait, violence is only necessary provided humans act nobly in all cases.
The futility you so blithely refer to is what we like to call the human condition. I certainly hope you get used to the fact that it does not live up to your expectations before you do something rash.
You may wish to illuminate the futility of either option; however, if there is nothing in this world, spiritual, personal, or material worth dying for, then there is nothing of worth in this world.
I believe that is true futility.
... it's Eric Engberg.
It's he, you may recall, whose one-sided political hatched job on Steve Forbes (referring to the flat tax as a "wacky scheme" in a straight news piece) convinced Bernard Goldberg to expose the MSM medias biases for what they are. Such exposure cost Bernard Goldberg the number 2 spot at CBS news and likely the anchor desk once someone pries it from Dan Rather's cold, dead hands.
Apparently journalism that states its biases and doesn't use codewords like "senior Administration officials" isn't journalism -- it's better, and we can't be having that.
The way I read the treaty is that so long as the orbital or deep space military installations do not utilize weapons of mass destruction, then they are not prohibited by treaty. Weapons of conventional destruction (such as kamikaze or focused microwave killersats) are unfriendly, but not prohibited. Even a cloud-to-ground tactical strike capability a la "the finger of $DEITY" would not be prohibited unless it utilized weapons of mass destruction.
Your mileage may vary.
If we posit that supporting weapons of mass destruction systems would also violate the treaty, well, then GPS violates it was well, as that can be used for tactical nuclear delivery systems (namely, finding where one is shooting from).
Precisely. The planning of the ability to exert space superiority does not violate the treaty. Possession of the means to exercise space superiority (or space denial, if you prefer) does not violate the treaty. Only if and only if USSpaceCom places weapons of mass destruction (nuclear, chemical, or biological according to the US definitions) in orbit or beyond is the US in violation ...
And conventional munitions are so very much more America's style. Sure, the occasional FAE munition is of use (for things like clearing a division-sized hole in the lines), but most of the time the United States military is concerned about putting ordnance on target, not scattering the rubble farther and wider. Killersats with the ability to preemptively strike other orbiting objects are completely legal -- and necessary, when one considers the signal and observation intelligence one can obtain through satellites.
Quoth Shakespeare: Cowards die many times before their deaths;The valiant never taste of death but once. I tend to think he's right.
Incorrect. Space superiority is the ability to *deny* occupation or use to the opposition.
Angelina Jolie will only play Honor Harrington in any media if and only if authorized by David Weber's estate (read: over his dead body), and I would not be surprised if he had a codicil in his will preventing such.
(For those who don't know, Angelina Jolie was able to adopt a Cambodian child in unbelievably expedited fashion while the Weber's adoption -- and seemingly everyone else who wasn't famous --was placed on bureaucratic hold.)
A thought experiment to demonstrate why this is incorrect, with the postulate we are not working at a quantum level:
Imagine a particle x.
If you know the exact location of this particle at some time t(0), and you know completely every vector constituting its movement until time tn....
Can you describe the exact location of particle X at time t(n), or at any time in between?
Modern, robust, ACID-compliant (and expensive) database systems use exactly this type of system to take read-consistent backups. All Oracle does is defer writes to a tablespace in backup mode to ensure all changes have been written as of the System Change Number (time t(0) in the above example) in the header file for every data file in the tablespace.
Heck, with those change vectors (as well as the rollback information), Oracle can tell allow you to *query* the database as of a given time. (within limitations, of course).
Actually, right field is not the place in baseball where the "lupus" plays once progressing past Little League, as the right fielder generally must be a more competent fielder and thrower to mitigate the number of first-to-third opportunities.
Well, when working on a COTS product, vendor lock-in is a real problem. Until, of course, you abstract all the database access to views to hide from the user the native calls required (like join syntax, and date conversion, and the like).
Then the problem is in your relational model. You need a record in the Job table akin to "No job." If the person has no job, link the job field in the person record to the "no job" record in the Job table. If there is no data regarding the job of that person (for example, no input data was provided), then NULL is completely correct.
Alternatively, you could set up the appropriate "indeterminate job" records in your job table and your question becomes much, much simpler. Of course, then you have to know exactly which indeterminate states you're looking for -- no data provided, invalid data provided, job person had was eliminated, and the like.
This would be a solution you'd probably use if the reason for the indeterminate nature of the state were relevant -- if your application doesn't care why the state is irrelevant, don't bother trying to map the reason and go with the NULL.
The value of NULL is that it means what it means -- namely, and indeterminate state. If you "know" someone has no job, using NULL is incorrect -- link the Person to the "no job" Job record.
Of course, that'd never happen without windows, like with the Solaris Uptime Bug, where you might have to reboot your Solaris server every 24 days.
http://sunportal.sunmanagers.org/pipermail/summ
Let's not pretend that Windows is the only tool in the shed that can be used to build a fragile system.