Working on different databases

From: Maciek (maksz_at_poczta.onet.pl)
Date: 04/23/04

  • Next message: Stephen Andrew Church: "Recursively Building Lists" 
    Date: 22 Apr 2004 17:43:28 -0700

    My situation is like that: I work on one, let's say basic database.
    There are most important facts in there. But sometimes, when I have no
    solution I want to support by the "less important" facts. My idea is
    to place them in diffrent database and use only if there is no other
    way of achieving the goal. What you think? Is it any elegant way of
    doing that, or maybe there is another, better solution?
    Asserting and retracting is not a way of doing that I think, as there
    are too many of these facts and they're not result from any rules.
    Besides that, after using a fact from the "supporting" database I'd
    like to take into account the "basic" one only in the next subgoal
    unless I can't find any solutions.
    I hope it's clear, if not or it's totally wrong question - forgive me
    I'm not too experienced in that problem.
    Thanx in advance,
    Maciek

  • Next message: Stephen Andrew Church: "Recursively Building Lists"

    Relevant Pages

    • Re: A real world example
      ... If a constraint is defined in terms of successive states of a database, ... Yes, that's all facts are, though constraints mean that your facts are ... model already allows surrogate keys. ...
      (comp.databases.theory)
    • Re: A real world example
      ... If a constraint is defined in terms of successive states of a database, ... facts cannot be thought of just in terms of instances of predicates. ... Yes, that's all facts are, though constraints mean that your facts are ...
      (comp.databases.theory)
    • Re: Wiki software for genealogy (long)
      ... those specific facts. ... Data can substantiate other data (although not prove ... documents of interest in my database. ... only connections I wish to make are all assumptions, either mapping a ...
      (soc.genealogy.britain)
    • Re: Database design, Keys and some other things
      ... except maybe that a database contains dead objects in the sense then as soon as they are in the database they stop behaving - food for another thread). ... some of their facts to establish that reason. ... to a refutation of the idea that there's any essential difference between the industry standard external identifier and the database-specific surrogate key: it's a matter of context merely, and not anything intrinsic to that data, or how it is managed. ... What is essential to this question is what their nature is. ...
      (comp.databases.theory)
    • Re: Where do business rules belong... OCP and SPs
      ... Database stuff is all about persistence. ... It's true that a database is a representation of facts, ... called business rules and they can and should be represented in the ... They are a lot better for that than general-purpose programming ...
      (comp.object)