single table structure- why not?

[SteveB]

Yes, it is a converted solution, and I've gotten rid of 100's and 100's of scripts. However, even if I wrote it from scratch, and it had 1000-1500 scripts, I can't see having them all in 1 file.

Steve

[Søren Dyhr]

Hmm, must be a converted solution. There's no need to have that many scripts in FM7/8

This is an interesting observation, it makes sense though ...since the scripts now are instances in their own right and not tied to a certain layout. But similar is it now established practice to move all layouts to TO's occuring in one file? This practice are at least reducing the scripts calling scripts in another file ...perhaps cutting the number of scripts to the half?

On top of that can a lot of standard tasks be put into merged recursive scripts since the paramter now ONLY is layout name/number and not jumps to different files. Take a look at Petrowskis video:

http://www.filemakermagazine.com/modules.php?op=modload&name=News&file=article&sid=622&mode=thread&order=0&thold=0

I would say because all layout's are moved to one file, doesn't allocation of scripts in different files prove anything but inconvenient?

--sd

[Razumovsky]

Allow me to post this question. Is not this single table idea nothing more than a really large "Multipurpose Table"?

Exactly, it is not complicated or fancy at all in that maner. But the model conceives of it more as a single-purpose table: for the purpose of holding data. We are normalizing our workflow as developers here. Having multiple tables for data is relationally akin to encountering a client that has an in-house designed DB with "Apples', 'Oranges,' and 'Pears' as separate tables in their structure.

I almost gave up on this - found that in a certain way I was spending a lot of time building FM3 using FM 8. I put it aside for a spell, but returned to it recently because I realized I had been working on a nearly identical problem in music/perception theory for the past year or so, and was making the same normalization errors there.

I have a solid working draft together (several steps up the evolutionary ladder from the Singles Table at the Champagne Room), but I can tell that the initial legwork for a practical version will be time consuming, and the file is already becoming a bit proprietary in nature.

I have made progress on a lot of the readability issues though (and there are a lot of them - the relational recursion helps tremendously with this however), and will strip down the file to a cleaner proof-of-concept next week when I get back from vacation (it is very sticky in Brooklyn about this time). I trust I will get some good feedback on what it is lacking and how to improve on it. Plus, I hope some of you might actually get a kick out of it.

I attached a little preview for now. This is derived from a Customer-Invoice-Item-Product relational state.

[Razumovsky]

Yes, it is a converted solution, and I've gotten rid of 100's and 100's of scripts. However, even if I wrote it from scratch, and it had 1000-1500 scripts, I can't see having them all in 1 file.

This is an interesting point that I had not considered. You could have a single table with multiple empty files for your scripts, but I have not really thought through those details.

It does seem like an excessive number of scripts, but regardless, it would be great to have a better way of organizing scripts in general. I think the new object functions will help a lot in normalizing scripting work as well (I think I may add a Script table).

If only there was an evaluate script step. Then you could have a field with text:

Set Field [$Field; "Whoopee!"]

[SteveB]

Neither you nor Ender has seen my solution, so how can you decide what constitutes a sufficient number of scripts?

My point is that Filemaker offers no way at all to sort, categorize, and display large numbers of scripts. Whether there are 500, 1000 or 3000 scripts, maintenance is still a issue, a BIG issue. And dumping everything into 1 file is not my idea of easy maintenance. We can't find orphaned scripts now, so why make the problem worse (yeah, I know there's the DDR (yuk) and FM Inspector). I know you've invested a lot of time in doing this, and under some conditions it probably will work very well, but I have doubts about a large solution.

Steve

[Razumovsky]

I didn't mean anything in particular about your solution Steve, I am sure if I went back and counted , some of mine would ring up there as well.

I think what we are saying is that there are many new ways to reduce the number of scripts needed. More relevantly, the issue you are describing belongs in the 'Single File Structure: Why not?' thread.

As I said above, I completely agree with you about the need for a better way of organizing scripts. Having multiple files purely as a means of script grouping seems pretty extreme to me.

[SteveB]

Am I wrong in assuming a Single Table means a Single File? Or are you splitting a single table across 2 or more files, in which case I gotta learn to read the entire thread, not just the last page.

Steve

[Razumovsky]

Yes, I think if you read the whole thread (get comfortable) it will be clear that your point is perhaps kind of related, but off topic.

What is being discussed here is the storage of user data. Could have one file, could have thousands, but only a single data table.

[Søren Dyhr]

We can't find orphaned scripts now, so why make the problem worse (yeah, I know there's the DDR (yuk) and FM Inspector)

It would be like rubbing salt in it, to say you could poke into your documentation. But I think there is a point in making a searchable database of all your scripts and layouts - by using this tool - watch this flash animation:

http://www.schubec.com/index.php?content[v][title]=fmpasteboard

This is the the URL to the Mac tool doing the same:

http://www.quart-edv.de/plugins/pasteboard_en.html

--sd

Edited July 14, 2006 by Guest

[teka]

I think that turning a DBMS with some relational capabilities into a manually controlled DBMS based on the hierarchical model, which was proven decades ago to be sub-optimal is not a new or even in my opinion a good idea.