Talk:ACID - Knowledge (XXG)

1520:

other, only that the discussion here does a poor job of defending the claim that there is no implication, and such an explanation is necessary since the above claim that there is an implication does sound plausible without closer inspection. I will provide some examples. I apologize that I'm not used to this doing this on Wikepedia and so the following is just a series of semi-colon delimited actions. A does not imply I: Assume transactions T1 and T2 are both attempting the same operation of reading M, writing M+1, reading N, writing N+5, where M equals 3 and N equals 10 before executing T1 and T2, and that our implementation guarantees A but not I; normally we expect that executing both transactions should result in a net M+2=5 and N+10=20; if A and not I, then we do not even need to pay attention to what is happening to M and we can prove I to be violated by watching only N (M is used below for other logic), and we could have the following use case (T1 reads N (10), T2 reads N (10) (violates I but not A), T1 adds - 10+5 = 15, T2 adds - 10+5 = 15 (violates I but not A), T1 writes N=15, T2 writes N=15 (does not violate A); both transactions commit successfully; the fact that we assert that the implementation enforces A is irrelevant in this specific use case since both transactions did complete successfully, but we assert it nonetheless, and indeed each transaction Tn was atomic; I was violated. A does not imply I. Next, I does not imply A: assume the same scenario we used for A does not imply I, except that we are using an implementation which guarantees I but does not guarantee A this time; if I and not A, then we could have the following use case (T1 reads M (3), T2 tries to read M but cannot because that would violate I so instead it waits, T1 adds to M - 3+1 = 4, T1 writes M = 4 successfully, T1 reads N but fails, T1 aborts but M=4 persists since we have not guaranteed A, now T2 is allowed to proceed and reads M (4), adds M - 4+1=5, writes M=5 successfully, reads N (10, because T1 did not successfully add to N), adds N - 10+5=15, writes N=15 successfully. We are left with a state of M=5, N=15 instead of M=5, N=20, and we don't have the M=4, N=15 we would normally expect if 1 of the transactions succeeded and the other failed. I was successfully guaranteed but A was not, therefore I does not imply A. Next, C and I does not imply A - for this one assume same situation as before except we also have a value X which equals 25 before T1 and T2 and there is a rule that M+N<X, and our implementation guarantees I and C but not A: I refer back to the same proof for "I does not imply A" and, from that use case we can trivially see that I is enforced by the same logic; and since M+N = 20, 20 < 25, C is also enforced (the transaction is not aborted because of C, so our C guarantee is upheld); and again referring back to "I does not imply A" we can see that, by the same logic, A is not enforced in this situation; therefore, I and C were enforced but A was not, therefore, I and C does not imply A. Next, A and C does not imply I; assume the same initial schema, values, and transaction actions as above, except this time our implementation guarantees A and C but not I; we have the following use case, (T1 reads M (3), T2 reads M (3) , T1 adds - 3+1=4, T2 adds - 3+1=4, T1 writes M=4, T2 writes M=4, T1 reads N (10), T1 adds - 10+5=15, T1 writes N=15 successfully, T2 reads N (15), T2 adds - 15+5=20, T2 writes N=20 successfully; on every successful write the rule M+N<X (M+N<25) is checked and is true for every write, so the rule correctly allows every write and our guarantee of C is not violated in this case; A was not violated in this case; I was very much violated since T1 and T2 had interleaving reads/writes to M; therefore, A and C does not imply I. This covers A-/-: -->

1401:. 2PL is used extensively on centralized databases. In fact, it is used in pretty much every database engine currently being used - especially ones that run on one server in a completely non-distributed environment. The point of 2PL is to ensure isolation because 2PL guarantees serializability. In other words, if you use 2PL, you are guaranteed that the result of multiple transactions running at the same time will be the same as at least one serialized ordering of those transactions - which is the definition of isolation. Youth was pointing out that the article clearly stated that 2PL was used to guarantee isolation, not atomicity. You replied by thoroughly misunderstanding his statement and then accusing him (and me?) of being a troll and lacking knowledge. I would be very amazed if anyone will take the time to try and explain this to you further as you have shown how you will respond. -- 1435:

certainly isn't used "in pretty much every database engine currently being used". It isn't used in in MS SQL Server 6.5/7/2000 and I'd be very surprised if it was used in oracle (though I don't know). Basically, full isolation for transactions is done by acquiring locks as they progress and in consequence they deadlock occasionally. Deadlock is detected by scanning the lock WaitFor graph for cycles then aborting & rolling back a transaction. You can, and I have, sometimes force SLA by manual hints but it's rare and only applicable in very simple or special cases. I really, really doubt it happens in general (or is even possible) and I'd question that claim on the wiki page. But back to my original question; now you've established a mechanism for Isolation, does not this isolation imply Atomicity? Because if you have I then apparently you have (the effect of) A, so I-: -->

1046:

The system may be messy and allow other transactions to access the data that my transaction is working on - changing it midway through. Here's an example: I want to read A, then read B, and then write the sum to C. So, it is atomic. Once I start reading A, I will guarantee that I read B and put the sum it C or I'll undo anything I've done. It is also consistent. In the end, C will have a number it in and that meets the requirements of the database. Now, I read A and it is 5. Then, I go to read B (which has a 2), but someone sneaks in real quick and changes it to 3. So, I end up reading a 3. I put the sum, 8, in C. For the record, it is durable. After I commit, that 8 stays in C. You can see that it met ACD, but did not meet I. A similar example is possible for every other property. --

1194:

nothing' rule" - (my ## emphasis). Not #actions# but #modifications#, which imply actions+data. Gray & Reuter's definition of Atomic is "Atomicity: A transaction's changes to the state are atomic: either all happen or none happen. These changes include database changes, messages, and actions on transducers" (Gray & Reuter, inside back cover). It say "changes to the state" which implies data + actions. I don't believe you can separate the two. Anyway, regardless of that I still feel that my core point above, that Isolated implies Atomic, still stands (until someone shows otherwise).

1228:. I can repeat over and over that in transaction management, atomic means nothing more than "all or nothing". It means other things in other areas of computer science, but not in transaction management. Perhaps if you get the same answer repeated by others, you will see that you are reading too much into the definitions you quoted. They do not claim that data is isolated for each transaction. The only claim that any modification/state change that is made implies that all modifications/state changes will be made. -- 1293:

changes), how you can claim that atomicity is only about functions (by which I presume you mean operations). Anyway how can you refer to all-or-nothing functions/operations without considering their changeing of some state - after all, without state changes how can the effect of any operation be other than null, always? And if a set of actions A is all-or-nothing on a state but that state is potentially being mutated unpredictably by other processes as A runs then what guarantees can A possibly make? None AFAICS.

410: 253: 679: 654: 222: 321: 345: 2524:

If a comma is inserted, it becomes a table constraint, and therefore any attempt to change A without also changing B would fail. Therefore, I don't think the example illustrates what it was intended to. To my knowledge, check constraints are always in force (unless something is done to turn them off), and I don't think transaction management of any kind is required to help them do their job.

191: 1965:

single centralized administration that gives permission to commit to one transaction at a time. If you go into distributed administration, then you need to figure out how to manage who can commit and when. Quorum is a simple solution to the problem which is rather fault tolerant - and it even handles the Byzantine problem if the consensus is higher than 1. --

2010:

Would it not be reasonable to drop all information related to "two-phase commit" as it's merely one solution enabling ACID, rather than a principle inherent to ACID ? Looks to me as specialized as the information on 'this dbms' or 'that dbms' or WAL or ... Implementations are interesting but overall

1690:

MySQL is a funny one. People who want to claim it is a tiny petty little thing ONLY consider the non-InnoDB version to justify their claims. Then, when you point out that the InooDB version of MySQL is ACID compliant, has foreign keys, and all that stuff, they say "Oh, I wasn't talking about that."

1117:

Consistency refers to a transaction not violating a DBs constraints. So It's irrelevant to this discussion, leaving only the question of how A & I relate, and whether one implies the other. I now think that when Isolation is defined as "Isolation: Even though transactions execute concurrently, it

1088:

I and there's a whiff of redundancy. Thinking about it I'm not sure exactly what some of the terms are - Atomic I'm pretty sure about, but Consistent? consistent with what? Isolated? from other transactions but in what sense is this isolation above and beyond that apparently ensure by Atomic alone? I

1045:

They do not imply one another. For example, I can have a transaction that is atomic. That means that once it starts, it must finish or all the work must be undone. It can be consistent. That means that the database must be consistent when the transaction commits. However, it may not be isolated.

959:

This has almost nothing to do with conformance to the constraints defined for the database. The word "consistency" might also be used in that context, but that is not what consistency refers to in the context of ACID transactions. Indeed, ACID transactions can be defined for non-relational systems

863:

If the unrelated query B tries to access some of the values beign modified by the A transaction, the database will wait till the transaction to finish, and give the data modified to the B query. If fact, modern databases will run the B query, wait for A, if A affects data readed by B, rollback B and

909:

I believe this part can be dropped, the person making the first comment did not quite know what he was talking about in the first place. Transactions are of course related to constraints and of course transactions can break constraints (in some DBMS's) and that is why ACID is not guaranteed in every

2523:

and says that if 10 is subtracted from A, then at that point the check constraint is false. As there is no comma in the example before the word CHECK, the constraint is a column constraint, and I don't believe it's legal to reference another column. (The example doesn't reference any SQL standard.)

1849:

It is definitely a complex matter to implement transactions in a DBMS. If database queries are arriving via a network, or via applications running on the same computer, makes little fundamental difference. I wonder if the original author was thinking of distributed or replicated data. The following

1326:

The quote you gave means exactly what it says. Altering the state means that something has changed in the database, for better or worse. It does not imply that the state change was intended or even that it the database will remain consistent. You are assuming correctness and consistency when all

955:

If ACID is a property of transactions in the face of concurrency, then Consistency needs to be defined in that context. In particular, offering a transaction a consistent view of the database means protecting the transaction from phantom reads. If a transaction reads data, and then reads the same

1850:

sentence mentioned two phase commit would suggest that. If so, the sentence should talk about distributed data, not a vague "network environment". If my assumption is correct, it would be better to expand the discussion of two phase commit a little rather than bring back the sentence I've deleted.

1633:

I doubt this. There are few databases out there that are truly ACID compliant, and even less that have any significant presence in the RDBMS space. In fact I think the list would consist entirely of Oracle, MSSQL, PostGreSQL, and Sybase. PostGreSQL would be debatable on the presence/penetration

1292:

2PC is for distributed transactions. I'm talking about the simpler sort for the moment, the non-distributed bog-standard transaction. And while you're here, can you explain with reference to the above definition by Gray & Reuter of Atomic, which talks explicitly about state changes (ie. *data*

1937:

thou there are ways even in a distributed environment use a single nodes to get simmeler effects. For instance you could put transaction numbers on all your records keeping one copy of the record for each transaction then have a single node that tracks the current transaction. In this way you can

1434:

Yup, my mistake. Then again had he used the phrase that appears in the page rather than the abbreviation, which doesn't, I might not have got confused. But that's just a triviality; I did misunderstand. I recognise what you call 2PL as Simultaneous Lock Acquisition (let's call it SLA) and it most

1519:

That's well and good, but it would have been nice for either one of you to share the highlights of this private conversation, as the comments here do not provide a convincing case that any one of the components of ACID do not imply the other. I am not saying that any one component does imply the

1193:

kainaw, that is a very, very odd interpretation of Atomic, and one I am having trouble buying into. I don't see how one can sustain a view that database actions can be divorced from the data they operate on. The wiki page sez "Atomicity states that database #modifications# must follow an 'all or

1964:

You are drifting from distributed databases to distributed database administration. Two-phase commit handles the problem of having one transaction commit while another is attempting to commit and causing a problem. It has nothing to do with how the administration is structured. It could be a

1079:

Doesn't make sense, sorry. 'Atomic' means a transaction logically happens in one step (or not at all). If it was atomic but other transactions could 'change it midway through' then it's not atomic because 'midway through' implies that the supposedly atomic action could be decomposed into parts

878:

transactions and have them run at the same time, the end result is consistent if and only if the database is in a consistent state when each transaction commits. It is not required that it be in an identical state that would result from running one transaction before the other transaction. --

1151:

common assumption that atomicity implies mutual exclusion - mainly because 90% of the time we combine atomicity with mutual exclusion. In this case, we only mean atomicity. In being atomic, this function does not exclude any other transaction from reading or writing to A and B while this

1023:

Hi all, I recall reading somewhere that one of the properties (atomic, consistent, isolated, durable) was implied by the others, something like "if a transaction is atomic and consistent then it must have had the appearance of being isolated". Or perhaps if it's A and I then it must appear

877:

That is not true. Consistency has nothing to do with the order of transactions. It has to do with the consistency of the database. A "consistent state" is a state in which the rules of the database, such as field values, foreign keys, and the like, are all met. So, if I interleave two

431: 2039:"One implementation relaxes the isolation property..." Does it really? From reading the page on snapshot isolation, it sounds as if the isolation requirement is not loosened at all. Snapshot isolation is just a means of implementing isolation without forcing total serialization. 867:

The result is that if B goes after A, the operations will be always the same, no mather if B was in T+1 when the trasaction A was still running or T+200. The virtual time for all the modifications that the transaction A makes is T, so any T+1 query will see that modifications in

940:

You're assuming a computer/OS can't be designed in a way that does allocate time in that way. You can imagine a company building a renderfarm and rents out computer time that would take advantage of something like that. For a real world example, the wolfram integrator

2194:

I suggest going back to a much earlier version that explains how that validation rule is either met or the update is reverted. Right now, someone has decided that it is more important to express limited knowledge of databases than to explain the concepts of ACID. --

1867:

Correct. I wrote that after working on information for federated databases. By "network environment", I am not referring to a single database with network capabilities. I am referring to a "database" spread over a network in multiple repositories. --

1118:

appers to each transaction, T, that others executed either before T or after T, but not both" - (Gray & Reuter, inside back cover, clearer IMO than the wiki page) I must assume that I implies A at least, and possibly the converse (though less sure).

956:

data again, it should be given the same result as before, barring any updates by the transaction itself. A violation of this law means that the DBMS is giving the transaction a time varying view of the data, and that's not consistent with itself.

1142:

You are correct that atomic means that all the operations must go through or none at all. It does not, however, refer to the data. It only refers to the operations. So, if a transaction is "read the value of A; write the value of A to B;", it

2411:

I believe this is definitely better, we're talking ACID, not 'whatever dbms you wanna talk about' and that's clear, is it possible to remove old discussions on which consensus has clearly been reached ? or move them to a history section ?

1938:

atomically update the data on all nodes ( if operations are ordered correctly ) with out the need for distrubeted consensus. Sorta MVCC for clusters. ( Sorry about the spelling. Spell check in google chorme sucks and so dose my spelling.)

1152:

transaction is operating. As far as isolation goes, when this transaction commits, the result of B should be the same as if this transaction ran without any other transactions running. So, it is completely different than atomicity. --

1269:

See the line near the end of the article that explains 2PL is normally used to guarantee isolation. It does not say atomicity. That is because atomicity has to do with the functions. Isolation has to do with the data.

1660:

Honestly, that barely scratches the surface of ACID databases; off the top of my head I can recall Berkeley DB, SQLite, Ingres, Firebird. PostgreSQL is no small player anymore. And yes, MySQL's InnoDB storage engine

1438:

I also). Because that's what I've been at all along. But feel free not to answer because by past standards I'm not going to get too much except diversions, and yes, I'm afraid you do appear to be lacking knowledge.

767:

I agree with the last statement, leave it as it is. When you see uppercase letters in a dictionary or encyclopedia, it means it is an acronym and it stands for something else. I think it is in the correct context.

872:

The article mentions consistency as "beign compliant with the constraints of the DB". Of course it is!. Constraints of the DB are unrelated with transactions! And of course transactions could not break them!

1736:

It's much funnier than that, InnoDB IS NOT ACID COMPLIANT... and anyone pretending the opposite neads to either learn more about how InnoDB handles triggers/ keys / cascades or learn what exactly is ACID.

153: 1492:

Kainaw responded privately and in detail. It is clear that he knows the subject in much greater depth than I do, or than I gave him credit for. I take back everything I said here that stated or implied

1080:

between which some outside interference could occur. Even if this interpretation was wrong, the 'Isolated' part should explicity ensure such interference doesn't happen, hence implying Consistent.

455: 595: 2069:

In the previous example, one rule was a requirement that A + B = 100; most database systems would not allow such a rule to be specified, and so would have no responsibility to enforce it.

1845:

It is difficult to guarantee ACID properties in a network environment. Network connections might fail, or two users might want to use the same part of the database at the same time.

2590: 512: 450: 2605: 816:

are two completely different articles. Knowledge (XXG) is case sensitive. If a user types ACID in all caps, it is most likely that the user is looking for this page. --

359: 1147:

means that both operations will take place. It does not imply that nothing will occur from another transaction between the read and write functions. You are making a

755:

I propose that the ACID article, being a disambiguation page, should mention both acid as in acidic chemicals, and also maybe mention that it is a nickname of LSD.

1904:

so that it's not ambiguous anymore. It's an quick introduction to distributed transactions so I personally find it appropriate. Does this sound good to you? --

945:) is designed to timeout if it performs an integral that takes too long. Just replace the integrator with something that uses transactions and it makes sense. 311: 147: 79: 2575: 301: 2600: 557: 2585: 335: 853:

If I remember correctly the "Consistency" in ACID refers to the fact that the Database must ensure that the order of the queries must be consistent:

372: 354: 236: 85: 531: 277: 930:"... it may have used up its allocated CPU time." - This doesn't seem to make too much sense. CPU time is not allocated, it's used on demand. - 979:

Correct me if I'm wrong but this is another 'Implementation' discussion, which I believe has no place in a principle /axiom article, cleanup ?

503: 2439:

is described. WAL writes the new (changed) data to a logfile which is copied to the database after the last previous read transaction ends.

1552:

Same question as for other parts, can we delete/drop/summarize some of the old discussions here in order to make the talk page more usable ?

736: 620: 1825:

is a judgement call (what is 'difficult') and the difficulty is related to general issues with multi-threading/concurrency, not networking.

2446: 2046: 1585: 1446: 1300: 30: 484: 2570: 1776: 1525: 1114:

And today's world prize for stupidity goes to me. What do the terms mean? Well, I'll find them in the wiki page which I'm commenting on.

2580: 685: 659: 260: 227: 99: 1641: 761:

I think that the above comment is outdated (as there is an "acid" and not "ACID" disambugation page). Someone please confirm this.

330: 232: 104: 20: 2397: 2248: 2179: 729:

ACID is IMHO a property of transactions in general, not necessarily in the context of DBMS. This should at least be mentioned.

74: 2610: 576: 541: 422: 202: 2595: 465: 65: 586: 44: 551: 1026:

Summat like that anyway, but I never found that quote again, nor anyone saying anything similar. Can anyone clarify?

1397:

Note that Youth mentioned 2PL. You replied with a comment about 2PC. 2PL is not 2PC. 2PL is an abbreviation for

1381:

A will have to wait for another day and someone knowledgeable. Thanks for the diversion, fruitless though it was.

168: 1001:

I subst'd the disambig link and changed it to point directly to the disambig. Figured I should mention it here. -

960:

that employ transactions, and conformance to constraints could be totally different in non-relational systems.

109: 1930: 740: 613: 135: 2543:

Seems like this tree is a bush--an article about 'transactions' could also reference 'structure'. Both ACID and

1857: 2450: 2156:

INSERT INTO acidtest VALUES (10, 10); ERROR: new row for relation "acidtest" violates check constraint "sum"

2050: 1589: 1450: 1304: 522: 208: 1780: 1529: 1092:

One day I'll have time to read Gray & Reuter or Vossen & Weikum, until then, thanks for your feedback

1943: 1806: 1332: 1275: 1007: 967: 2442: 2042: 1637: 1581: 1442: 1296: 732: 690: 664: 2552: 2544: 1926: 1498: 1473: 1386: 1362: 1199: 1125: 1099: 1034: 273: 1083:

I believe Durability is irrelevant here; it's a requirement tangential to the rest hence let's ignore it.

55: 1939: 1645: 276:

on Knowledge (XXG). If you would like to participate, please visit the project page, where you can join

1494: 1469: 1382: 1358: 1195: 1121: 1095: 1030: 963: 70: 1380:

Ah! foolish me! I do believe I've been trolled and totally had! Well the question of whether I -: -->

129: 2388: 2239: 2170: 2086: 788: 777: 1390: 1038: 441: 190: 2525: 2413: 2012: 1853: 1738: 1553: 980: 911: 161: 2529: 2417: 2016: 1802: 1742: 1557: 1328: 1271: 1002: 984: 915: 125: 1524:

I. This is getting long enough and taking long enough that I will forego discussing D. -Aaron

946: 758:

These are all fairly common uses of the word ACID, and thus should be reflected in the article.

2548: 1801:

Just curious whether recent document/JSON no-SQL databases like MongoDB and CouchDB are ACID.

1398: 51: 1634:

side as well. Many databases claim to be ACID compliant but in fact are not, such as MySQL.

567: 2216: 1986: 1933:. It is my understanding the the only way for more then one node to agree on a state is the 1889: 1712: 1621: 1422: 1249: 1173: 1067: 899: 837: 493: 175: 2153:

attempting to insert a row in violation of the A + B = 100 constraint results in an error:

2378: 2229: 2160: 2082: 1934: 1909: 1670: 1089:

am more sure now of redundancy, but even less sure of what each component of ACI(D) means.

1600:

The list would be much longer than the article itself. It would be rather pointless. --

1225: 409: 432:

Requested articles/Applied arts and sciences/Computer science, computing, and Internet

2564: 774:

I agree. A disambiguation page should not contain detailed info on one definition.

141: 2196: 1966: 1869: 1692: 1601: 1402: 1229: 1153: 1047: 879: 817: 764:

you mean "Acid", this one is about chemicals I think everything's ok as it is..

678: 653: 320: 252: 221: 2078: 1905: 1666: 1578:

Should there be a list near the end of the article of products that conform?

931: 474: 269: 344: 942: 265: 2263: 1827:

Two-phase commit is typically applied in distributed transactions ...

1823:

It is difficult to guarantee ACID properties in a network environment

1772: 1821:

I've added citation requests to three egregious statements, namely:

1831:

Two phase locking is typically applied to guarantee full isolation.

910:

case, and that is why it was defined and required to be enforced.

2074: 2089:

all can. Under PostgreSQL, with the following table definition:

1775:

wikipedia page (or at least bring it up on the talk page there).

813: 809: 24: 1925:

Two phase commit is not sufhichent to solve this problime. See

550:

Find pictures for the biographies of computer scientists (see

184: 15: 343: 319: 2556: 2533: 2454: 2421: 2406: 2257: 2224:

I've restored the content in "Consistency failure" before

2219: 2188: 2054: 2020: 1989: 1947: 1912: 1892: 1861: 1810: 1784: 1746: 1715: 1673: 1624: 1593: 1561: 1533: 1502: 1477: 1454: 1425: 1366: 1336: 1308: 1279: 1252: 1203: 1176: 1129: 1103: 1070: 1012: 988: 971: 949: 934: 919: 902: 840: 791: 744: 2159:

What should be done with this statement in the article?

1437:

CID (and there's still my question as to whether A-: -->

2225: 1901: 398: 393: 388: 383: 1665:

ACID; what sources do you have to claim otherwise? --

160: 776:

Most of the contents of this page should be moved to

264:, a collaborative effort to improve the coverage of 1224:Please ask this on the computer science section of 174: 1841:I have removed the following sentence altogether: 456:Computer science articles needing expert attention 1902:I re-added and hopefully clarified the statement 688:, a project which is currently considered to be 33:for general discussion of the article's subject. 1829:, citation request should be self explanatory. 596:WikiProject Computer science/Unreferenced BLPs 1357:(Please see bottom of this discussion thread) 8: 2591:C-Class software articles of Mid-importance 513:Computer science articles without infoboxes 451:Computer science articles needing attention 1574:Databases That Conform To ACID Principles? 1086:So I don't buy it. It seems to me AI-: --> 648: 417:Here are some tasks awaiting attention: 367: 216: 2606:High-importance Computer science articles 857:Imagine a transacction A starts on time T 860:Another unrelated query B starts at T+1 650: 218: 188: 943:http://integrals.wolfram.com/index.jsp 700:Knowledge (XXG):WikiProject Databases 286:Knowledge (XXG):WikiProject Computing 7: 684:This article is within the scope of 258:This article is within the scope of 2011:irrelevant to the ACID principles. 207:It is of interest to the following 23:for discussing improvements to the 2576:High-importance Computing articles 2547:seem to be on par meta-concepts. 2465:The main page gives this example: 2077:cannot enforce check constraints, 532:Timeline of computing 2020–present 14: 2601:C-Class Computer science articles 558:Computing articles needing images 50:New to Knowledge (XXG)? Welcome! 2586:Mid-importance software articles 2061:Integrity constraint enforcement 2035:Relaxing the isolation property? 677: 652: 408: 251: 220: 189: 45:Click here to start a new topic. 306:This article has been rated as 1913:12:51, 28 September 2009 (UTC) 1893:11:45, 27 September 2009 (UTC) 1862:03:54, 27 September 2009 (UTC) 1716:13:17, 18 September 2009 (UTC) 1674:08:09, 18 September 2009 (UTC) 1327:that is said is state change. 935:05:09, 18 September 2005 (UTC) 703:Template:WikiProject Databases 289:Template:WikiProject Computing 1: 1625:20:47, 26 February 2009 (UTC) 1071:20:51, 26 February 2009 (UTC) 950:04:58, 25 December 2005 (UTC) 903:20:45, 26 February 2009 (UTC) 612:Tag all relevant articles in 352:This article is supported by 328:This article is supported by 280:and see a list of open tasks. 42:Put new text under old text. 2455:07:43, 25 January 2013 (UTC) 2266:honors the check constraint: 1990:05:24, 12 January 2010 (UTC) 1948:22:03, 11 January 2010 (UTC) 1594:06:16, 25 October 2008 (UTC) 1013:18:02, 29 January 2006 (UTC) 841:13:24, 14 January 2010 (UTC) 792:13:24, 8 December 2005 (UTC) 745:09:19, 14 January 2010 (UTC) 621:WikiProject Computer science 373:WikiProject Computer science 355:WikiProject Computer science 2422:11:36, 19 August 2011 (UTC) 2228:. I'll clean it up later. 2021:11:39, 19 August 2011 (UTC) 1811:11:34, 14 August 2018 (UTC) 1747:11:41, 19 August 2011 (UTC) 1562:11:42, 19 August 2011 (UTC) 1534:15:42, 24 August 2016 (UTC) 989:11:44, 19 August 2011 (UTC) 972:11:11, 1 October 2010 (UTC) 920:11:45, 19 August 2011 (UTC) 552:List of computer scientists 2627: 2571:C-Class Computing articles 2557:19:04, 14 April 2020 (UTC) 2407:17:59, 30 March 2011 (UTC) 2258:17:32, 30 March 2011 (UTC) 2220:12:49, 30 March 2011 (UTC) 2189:12:43, 30 March 2011 (UTC) 1503:14:57, 12 March 2009 (UTC) 1478:14:57, 12 March 2009 (UTC) 1367:14:57, 12 March 2009 (UTC) 1040:22:54, 22 April 2008 (UTC) 808:the disambiguation page. 312:project's importance scale 2581:C-Class software articles 2073:This is not true. While 2065:The article states that: 1931:Byzantine_fault_tolerance 1455:00:30, 7 March 2009 (UTC) 1426:22:38, 6 March 2009 (UTC) 1392:19:12, 6 March 2009 (UTC) 1337:16:45, 6 March 2009 (UTC) 1309:15:47, 6 March 2009 (UTC) 1280:14:06, 6 March 2009 (UTC) 1253:20:02, 5 March 2009 (UTC) 1204:14:54, 4 March 2009 (UTC) 1177:22:33, 3 March 2009 (UTC) 1130:09:43, 2 March 2009 (UTC) 1104:09:13, 2 March 2009 (UTC) 672: 614:Category:Computer science 366: 351: 327: 305: 246: 215: 80:Be welcoming to newcomers 2467: 2271: 2091: 2055:19:26, 3 June 2010 (UTC) 1785:20:35, 16 May 2012 (UTC) 1771:If that's true, fix the 864:repeat that query again. 616:and sub-categories with 2534:16:16, 9 May 2013 (UTC) 2611:All Computing articles 2545:Database normalization 2071: 577:Computer science stubs 348: 324: 274:information technology 197:This article is rated 75:avoid personal attacks 2596:All Software articles 2067: 1927:Two_Generals'_Problem 686:WikiProject Databases 347: 323: 261:WikiProject Computing 201:on Knowledge (XXG)'s 100:Neutral point of view 2087:Microsoft SQL Server 1436:A and so ACID -: --> 371:Things you can help 331:WikiProject Software 105:No original research 2539:See Also suggestion 2433:write ahead logging 2427:Write ahead logging 1837:Network environment 1468:(paragraph removed) 1005: 926:Allocated CPU time 706:Databases articles 349: 325: 292:Computing articles 203:content assessment 86:dispute resolution 47: 2461:Error in example? 2445:comment added by 2437:pre image logging 2402: 2393: 2383: 2253: 2244: 2234: 2184: 2175: 2165: 2045:comment added by 1911: 1833:, same as above. 1672: 1640:comment added by 1584:comment added by 1445:comment added by 1399:two phase locking 1299:comment added by 1003: 735:comment added by 722: 721: 718: 717: 714: 713: 647: 646: 643: 642: 639: 638: 635: 634: 183: 182: 66:Assume good faith 43: 2618: 2519: 2516: 2513: 2510: 2507: 2504: 2501: 2498: 2495: 2492: 2489: 2486: 2483: 2480: 2477: 2474: 2471: 2457: 2403: 2400: 2394: 2391: 2385: 2381: 2374: 2371: 2368: 2365: 2362: 2359: 2356: 2353: 2350: 2347: 2344: 2341: 2338: 2335: 2332: 2329: 2326: 2323: 2320: 2317: 2314: 2311: 2308: 2305: 2302: 2299: 2296: 2293: 2290: 2287: 2284: 2281: 2278: 2275: 2254: 2251: 2245: 2242: 2236: 2232: 2214: 2211: 2208: 2205: 2202: 2199: 2185: 2182: 2176: 2173: 2167: 2163: 2149: 2146: 2143: 2140: 2137: 2134: 2131: 2128: 2125: 2122: 2119: 2116: 2113: 2110: 2107: 2104: 2101: 2098: 2095: 2057: 1984: 1981: 1978: 1975: 1972: 1969: 1908: 1887: 1884: 1881: 1878: 1875: 1872: 1710: 1707: 1704: 1701: 1698: 1695: 1669: 1649: 1619: 1616: 1613: 1610: 1607: 1604: 1596: 1457: 1420: 1417: 1414: 1411: 1408: 1405: 1391:_AID?_ACD?": --> 1311: 1247: 1244: 1241: 1238: 1235: 1232: 1171: 1168: 1165: 1162: 1159: 1156: 1065: 1062: 1059: 1056: 1053: 1050: 1039:_AID?_ACD?": --> 897: 894: 891: 888: 885: 882: 835: 832: 829: 826: 823: 820: 747: 708: 707: 704: 701: 698: 681: 674: 673: 668: 656: 649: 625: 619: 494:Computer science 423:Article requests 412: 405: 404: 368: 294: 293: 290: 287: 284: 255: 248: 247: 242: 239: 224: 217: 200: 194: 193: 185: 179: 178: 164: 95:Article policies 16: 2626: 2625: 2621: 2620: 2619: 2617: 2616: 2615: 2561: 2560: 2541: 2521: 2520: 2517: 2514: 2511: 2508: 2505: 2502: 2499: 2496: 2493: 2490: 2487: 2484: 2481: 2478: 2475: 2472: 2469: 2463: 2440: 2429: 2398: 2389: 2379: 2376: 2375: 2372: 2369: 2366: 2363: 2360: 2357: 2354: 2351: 2348: 2345: 2342: 2339: 2336: 2333: 2330: 2327: 2324: 2321: 2318: 2315: 2312: 2309: 2306: 2303: 2300: 2297: 2294: 2291: 2288: 2285: 2282: 2279: 2276: 2273: 2249: 2240: 2230: 2212: 2209: 2206: 2203: 2200: 2197: 2180: 2171: 2161: 2157: 2151: 2150: 2147: 2144: 2141: 2138: 2135: 2132: 2129: 2126: 2123: 2120: 2117: 2114: 2111: 2108: 2105: 2102: 2099: 2096: 2093: 2083:Oracle Database 2063: 2040: 2037: 1982: 1979: 1976: 1973: 1970: 1967: 1935:Paxos_algorithm 1885: 1882: 1879: 1876: 1873: 1870: 1839: 1819: 1708: 1705: 1702: 1699: 1696: 1693: 1635: 1617: 1614: 1611: 1608: 1605: 1602: 1579: 1576: 1440: 1418: 1415: 1412: 1409: 1406: 1403: 1294: 1245: 1242: 1239: 1236: 1233: 1230: 1169: 1166: 1163: 1160: 1157: 1154: 1063: 1060: 1057: 1054: 1051: 1048: 1021: 999: 928: 895: 892: 889: 886: 883: 880: 851: 833: 830: 827: 824: 821: 818: 789:gorgan_almighty 778:ACID (database) 753: 737:193.135.254.161 730: 727: 705: 702: 699: 696: 695: 662: 631: 628: 623: 617: 605:Project-related 600: 581: 562: 536: 517: 498: 479: 460: 436: 403: 360:High-importance 308:High-importance 291: 288: 285: 282: 281: 241:High‑importance 240: 230: 198: 121: 116: 115: 114: 91: 61: 12: 11: 5: 2624: 2622: 2614: 2613: 2608: 2603: 2598: 2593: 2588: 2583: 2578: 2573: 2563: 2562: 2540: 2537: 2468: 2462: 2459: 2447:212.152.157.50 2428: 2425: 2272: 2270: 2269: 2268: 2267: 2260: 2155: 2092: 2062: 2059: 2047:24.238.213.117 2036: 2033: 2032: 2031: 2030: 2029: 2028: 2027: 2026: 2025: 2024: 2023: 1999: 1998: 1997: 1996: 1995: 1994: 1993: 1992: 1955: 1954: 1953: 1952: 1951: 1950: 1918: 1917: 1916: 1915: 1896: 1895: 1854:Paul Foxworthy 1838: 1835: 1818: 1815: 1814: 1813: 1798: 1797: 1796: 1795: 1794: 1793: 1792: 1791: 1790: 1789: 1788: 1787: 1758: 1757: 1756: 1755: 1754: 1753: 1752: 1751: 1750: 1749: 1725: 1724: 1723: 1722: 1721: 1720: 1719: 1718: 1681: 1680: 1679: 1678: 1677: 1676: 1653: 1652: 1651: 1650: 1628: 1627: 1586:218.215.25.240 1575: 1572: 1571: 1570: 1569: 1568: 1567: 1566: 1565: 1564: 1543: 1542: 1541: 1540: 1539: 1538: 1537: 1536: 1510: 1509: 1508: 1507: 1506: 1505: 1485: 1484: 1483: 1482: 1481: 1480: 1461: 1460: 1459: 1458: 1447:78.151.158.196 1429: 1428: 1378: 1377: 1376: 1375: 1374: 1373: 1372: 1371: 1370: 1369: 1346: 1345: 1344: 1343: 1342: 1341: 1340: 1339: 1317: 1316: 1315: 1314: 1313: 1312: 1301:78.151.135.219 1285: 1284: 1283: 1282: 1264: 1263: 1262: 1261: 1260: 1259: 1258: 1257: 1256: 1255: 1213: 1212: 1211: 1210: 1209: 1208: 1207: 1206: 1184: 1183: 1182: 1181: 1180: 1179: 1135: 1134: 1133: 1132: 1119: 1115: 1109: 1108: 1107: 1106: 1093: 1090: 1084: 1081: 1074: 1073: 1029: 1027: 1025: 1020: 1016: 1010: 998: 995: 994: 993: 992: 991: 953: 952: 927: 924: 923: 922: 906: 905: 870: 869: 865: 861: 858: 850: 847: 846: 845: 844: 843: 799: 798: 797: 796: 795: 794: 782: 781: 775: 752: 749: 726: 723: 720: 719: 716: 715: 712: 711: 709: 682: 670: 669: 657: 645: 644: 641: 640: 637: 636: 633: 632: 630: 629: 627: 626: 609: 601: 599: 598: 592: 582: 580: 579: 573: 563: 561: 560: 555: 547: 537: 535: 534: 528: 518: 516: 515: 509: 499: 497: 496: 490: 480: 478: 477: 471: 461: 459: 458: 453: 447: 437: 435: 434: 428: 416: 414: 413: 402: 401: 396: 391: 386: 380: 377: 376: 364: 363: 350: 340: 339: 336:Mid-importance 326: 316: 315: 304: 298: 297: 295: 278:the discussion 256: 244: 243: 225: 213: 212: 206: 195: 181: 180: 118: 117: 113: 112: 107: 102: 93: 92: 90: 89: 82: 77: 68: 62: 60: 59: 48: 39: 38: 35: 34: 28: 13: 10: 9: 6: 4: 3: 2: 2623: 2612: 2609: 2607: 2604: 2602: 2599: 2597: 2594: 2592: 2589: 2587: 2584: 2582: 2579: 2577: 2574: 2572: 2569: 2568: 2566: 2559: 2558: 2554: 2550: 2546: 2538: 2536: 2535: 2531: 2527: 2466: 2460: 2458: 2456: 2452: 2448: 2444: 2438: 2435:is used, but 2434: 2426: 2424: 2423: 2419: 2415: 2409: 2408: 2404: 2395: 2386: 2265: 2261: 2259: 2255: 2246: 2237: 2227: 2223: 2222: 2221: 2218: 2215: 2193: 2192: 2191: 2190: 2186: 2177: 2168: 2154: 2090: 2088: 2084: 2080: 2076: 2070: 2066: 2060: 2058: 2056: 2052: 2048: 2044: 2034: 2022: 2018: 2014: 2009: 2008: 2007: 2006: 2005: 2004: 2003: 2002: 2001: 2000: 1991: 1988: 1985: 1963: 1962: 1961: 1960: 1959: 1958: 1957: 1956: 1949: 1945: 1941: 1940:Wikiwikimoore 1936: 1932: 1928: 1924: 1923: 1922: 1921: 1920: 1919: 1914: 1910: 1907: 1903: 1900: 1899: 1898: 1897: 1894: 1891: 1888: 1866: 1865: 1864: 1863: 1859: 1855: 1851: 1847: 1846: 1842: 1836: 1834: 1832: 1828: 1824: 1816: 1812: 1808: 1804: 1803:David Spector 1800: 1799: 1786: 1782: 1778: 1777:67.207.113.90 1774: 1770: 1769: 1768: 1767: 1766: 1765: 1764: 1763: 1762: 1761: 1760: 1759: 1748: 1744: 1740: 1735: 1734: 1733: 1732: 1731: 1730: 1729: 1728: 1727: 1726: 1717: 1714: 1711: 1689: 1688: 1687: 1686: 1685: 1684: 1683: 1682: 1675: 1671: 1668: 1664: 1659: 1658: 1657: 1656: 1655: 1654: 1647: 1643: 1639: 1632: 1631: 1630: 1629: 1626: 1623: 1620: 1599: 1598: 1597: 1595: 1591: 1587: 1583: 1573: 1563: 1559: 1555: 1551: 1550: 1549: 1548: 1547: 1546: 1545: 1544: 1535: 1531: 1527: 1526:67.246.97.194 1523:A, AC-/-: --> 1522:A, IC-/-: --> 1518: 1517: 1516: 1515: 1514: 1513: 1512: 1511: 1504: 1500: 1496: 1491: 1490: 1489: 1488: 1487: 1486: 1479: 1475: 1471: 1467: 1466: 1465: 1464: 1463: 1462: 1456: 1452: 1448: 1444: 1433: 1432: 1431: 1430: 1427: 1424: 1421: 1400: 1396: 1395: 1394: 1393: 1388: 1384: 1368: 1364: 1360: 1356: 1355: 1354: 1353: 1352: 1351: 1350: 1349: 1348: 1347: 1338: 1334: 1330: 1329:Youth in Asia 1325: 1324: 1323: 1322: 1321: 1320: 1319: 1318: 1310: 1306: 1302: 1298: 1291: 1290: 1289: 1288: 1287: 1286: 1281: 1277: 1273: 1272:Youth in Asia 1268: 1267: 1266: 1265: 1254: 1251: 1248: 1227: 1223: 1222: 1221: 1220: 1219: 1218: 1217: 1216: 1215: 1214: 1205: 1201: 1197: 1192: 1191: 1190: 1189: 1188: 1187: 1186: 1185: 1178: 1175: 1172: 1150: 1146: 1141: 1140: 1139: 1138: 1137: 1136: 1131: 1127: 1123: 1120: 1116: 1113: 1112: 1111: 1110: 1105: 1101: 1097: 1094: 1091: 1087:C or AC-: --> 1085: 1082: 1078: 1077: 1076: 1075: 1072: 1069: 1066: 1044: 1043: 1042: 1041: 1036: 1032: 1017: 1015: 1014: 1011: 1008: 1006: 996: 990: 986: 982: 978: 977: 976: 975: 974: 973: 969: 965: 961: 957: 951: 948: 944: 939: 938: 937: 936: 933: 925: 921: 917: 913: 908: 907: 904: 901: 898: 876: 875: 874: 866: 862: 859: 856: 855: 854: 848: 842: 839: 836: 815: 811: 807: 803: 802: 801: 800: 793: 790: 786: 785: 784: 783: 779: 773: 772: 771: 770: 769: 765: 762: 759: 756: 750: 748: 746: 742: 738: 734: 724: 710: 693: 692: 687: 683: 680: 676: 675: 671: 666: 661: 658: 655: 651: 622: 615: 611: 610: 608: 606: 602: 597: 594: 593: 591: 589: 588: 583: 578: 575: 574: 572: 570: 569: 564: 559: 556: 553: 549: 548: 546: 544: 543: 538: 533: 530: 529: 527: 525: 524: 519: 514: 511: 510: 508: 506: 505: 500: 495: 492: 491: 489: 487: 486: 481: 476: 473: 472: 470: 468: 467: 462: 457: 454: 452: 449: 448: 446: 444: 443: 438: 433: 430: 429: 427: 425: 424: 419: 418: 415: 411: 407: 406: 400: 397: 395: 392: 390: 387: 385: 382: 381: 379: 378: 374: 370: 369: 365: 361: 358:(assessed as 357: 356: 346: 342: 341: 337: 334:(assessed as 333: 332: 322: 318: 317: 313: 309: 303: 300: 299: 296: 279: 275: 271: 267: 263: 262: 257: 254: 250: 249: 245: 238: 234: 229: 226: 223: 219: 214: 210: 204: 196: 192: 187: 186: 177: 173: 170: 167: 163: 159: 155: 152: 149: 146: 143: 140: 137: 134: 131: 127: 124: 123:Find sources: 120: 119: 111: 110:Verifiability 108: 106: 103: 101: 98: 97: 96: 87: 83: 81: 78: 76: 72: 69: 67: 64: 63: 57: 53: 52:Learn to edit 49: 46: 41: 40: 37: 36: 32: 26: 22: 18: 17: 2549:Xtian~enwiki 2542: 2522: 2464: 2441:— Preceding 2436: 2432: 2430: 2410: 2377: 2158: 2152: 2072: 2068: 2064: 2038: 1852: 1848: 1844: 1843: 1840: 1830: 1826: 1822: 1820: 1662: 1636:— Preceding 1577: 1521:I, I-/-: --> 1495:Water pepper 1470:Water pepper 1383:Water pepper 1379: 1359:Water pepper 1196:Water pepper 1148: 1144: 1122:Water pepper 1096:Water pepper 1031:Water pepper 1022: 1000: 964:Joe Thursday 962: 958: 954: 929: 871: 852: 805: 766: 763: 760: 757: 754: 728: 689: 604: 603: 587:Unreferenced 585: 584: 566: 565: 540: 539: 521: 520: 502: 501: 483: 482: 464: 463: 440: 439: 421: 420: 353: 329: 307: 259: 209:WikiProjects 171: 165: 157: 150: 144: 138: 132: 122: 94: 19:This is the 2041:—Preceding 1642:173.9.86.65 1580:—Preceding 1441:—Preceding 1295:—Preceding 1018:ACID -: --> 849:Consistency 731:—Preceding 148:free images 31:not a forum 2565:Categories 2370:constraint 2121:CONSTRAINT 2079:PostgreSQL 1493:otherwise. 725:DBMS Only? 2431:The term 2226:this edit 1817:Citations 1019:AID? ACD? 697:Databases 660:Databases 475:Computing 283:Computing 270:computing 266:computers 228:Computing 88:if needed 71:Be polite 21:talk page 2526:Rochkind 2476:acidtest 2443:unsigned 2414:Yourbane 2343:acidtest 2286:acidtest 2100:acidtest 2043:unsigned 2013:Yourbane 1739:Yourbane 1638:unsigned 1582:unsigned 1554:Yourbane 1443:unsigned 1297:unsigned 1028:ta - jan 997:Disambig 981:Yourbane 912:Yourbane 804:This is 751:Proposal 733:unsigned 691:inactive 665:inactive 523:Maintain 466:Copyedit 233:Software 56:get help 29:This is 27:article. 2494:INTEGER 2485:INTEGER 2401:ONTRIBS 2304:INTEGER 2295:INTEGER 2252:ONTRIBS 2183:ONTRIBS 2118:INTEGER 2109:INTEGER 1009:Simpson 504:Infobox 442:Cleanup 389:history 310:on the 237:CompSci 199:C-class 154:WP refs 142:scholar 2470:CREATE 2373:failed 2346:VALUES 2337:INSERT 2331:sqlite 2280:CREATE 2274:sqlite 2264:SQLite 2094:CREATE 2085:, and 1773:InnoDB 1004:Corbin 868:place. 485:Expand 272:, and 205:scale. 126:Google 2497:CHECK 2473:TABLE 2382:RAGON 2364:Error 2334:: --> 2307:CHECK 2283:TABLE 2277:: --> 2262:Even 2233:RAGON 2164:RAGON 2127:CHECK 2097:TABLE 2075:MySQL 1906:intgr 1667:intgr 1226:WP:RD 947:TomJF 932:intgr 568:Stubs 542:Photo 399:purge 394:watch 375:with: 169:JSTOR 130:books 84:Seek 2553:talk 2530:talk 2451:talk 2418:talk 2384:280 2340:INTO 2235:280 2166:280 2051:talk 2017:talk 1944:talk 1929:and 1858:talk 1807:talk 1781:talk 1743:talk 1646:talk 1590:talk 1558:talk 1530:talk 1499:talk 1474:talk 1451:talk 1387:talk 1363:talk 1333:talk 1305:talk 1276:talk 1200:talk 1149:very 1145:only 1126:talk 1100:talk 1035:talk 985:talk 968:talk 916:talk 814:ACID 812:and 810:acid 741:talk 384:edit 302:High 162:FENS 136:news 73:and 25:ACID 2518:)); 2515:100 2392:ALK 2328:)); 2325:100 2243:ALK 2174:ALK 2148:)); 2145:100 2124:sum 1691:-- 806:not 176:TWL 2567:: 2555:) 2532:) 2453:) 2420:) 2405:) 2361:); 2358:10 2352:10 2256:) 2187:) 2081:, 2053:) 2019:) 1946:) 1860:) 1809:) 1783:) 1745:) 1663:is 1648:) 1592:) 1560:) 1532:) 1501:) 1476:) 1453:) 1389:) 1365:) 1335:) 1307:) 1278:) 1202:) 1128:) 1102:) 1037:) 1024:C. 987:) 970:) 918:) 743:) 624:}} 618:{{ 362:). 338:). 268:, 235:/ 231:: 156:) 54:; 2551:( 2528:( 2512:= 2509:B 2506:+ 2503:A 2500:( 2491:B 2488:, 2482:A 2479:( 2449:( 2416:( 2399:C 2396:/ 2390:T 2387:( 2380:D 2367:: 2355:, 2349:( 2322:= 2319:B 2316:+ 2313:A 2310:( 2301:B 2298:, 2292:A 2289:( 2250:C 2247:/ 2241:T 2238:( 2231:D 2217:™ 2213:w 2210:a 2207:n 2204:i 2201:a 2198:k 2181:C 2178:/ 2172:T 2169:( 2162:D 2142:= 2139:B 2136:+ 2133:A 2130:( 2115:B 2112:, 2106:A 2103:( 2049:( 2015:( 1987:™ 1983:w 1980:a 1977:n 1974:i 1971:a 1968:k 1942:( 1890:™ 1886:w 1883:a 1880:n 1877:i 1874:a 1871:k 1856:( 1805:( 1779:( 1741:( 1713:™ 1709:w 1706:a 1703:n 1700:i 1697:a 1694:k 1644:( 1622:™ 1618:w 1615:a 1612:n 1609:i 1606:a 1603:k 1588:( 1556:( 1528:( 1497:( 1472:( 1449:( 1423:™ 1419:w 1416:a 1413:n 1410:i 1407:a 1404:k 1385:( 1361:( 1331:( 1303:( 1274:( 1250:™ 1246:w 1243:a 1240:n 1237:i 1234:a 1231:k 1198:( 1174:™ 1170:w 1167:a 1164:n 1161:i 1158:a 1155:k 1124:( 1098:( 1068:™ 1064:w 1061:a 1058:n 1055:i 1052:a 1049:k 1033:( 983:( 966:( 941:( 914:( 900:™ 896:w 893:a 890:n 887:i 884:a 881:k 838:™ 834:w 831:a 828:n 825:i 822:a 819:k 787:— 780:. 739:( 694:. 667:) 663:( 607:: 590:: 571:: 554:) 545:: 526:: 507:: 488:: 469:: 445:: 426:: 314:. 211:: 172:· 166:· 158:· 151:· 145:· 139:· 133:· 128:( 58:.

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Index