Re: [RLC-Action] Re: Media Contact Database
- westmiller@... wrote:
> From: "Chuck Seberg" <pusherprop3@...>It's easily done--export it to a comma-delimited file,
> > My other concerns still stand.
> You're correct about a direct import from csv to SQL: the fields and
> types do have to match. However, there are dozens of programming
> methods aside from those two facilities that can be used to make a
> conversion of the field structure, type and sequence for all records
> from one to the other.
> Having said that, I don't have the time to convert my existing
> media database to either Yahoo! DB or SQL.
then import it. All the character fields will be char
fields. It shouldn't take more than an hour, tops.
> There are over 800The number of records isn't relevant to how much time
> records in FoxPro (dBase) DBF format, but mostly with emails only.
> Here's my structure, which may be useful in deciding on fields:
or trouble it would take, unless they contain illegal
characters, like commas.
\ / ASCII RIBBON CAMPAIGN || Alcohol, Tobacco, and Firearms
X AGAINST HTML MAIL || should be a convenience store,
/ \ AND POSTINGS || not a government agency.
How long do you think it would take to develop a front end for the database?
From: RLC-Action@yahoogroups.com [mailto: RLC-Action@yahoogroups.com ] On Behalf Of Mike Bryant
Sent: Wednesday, June 01, 2005 3:32 PM
To: RLC-Action@yahoogroups.com ; DGHarrison
Subject: Re: [RLC-Action] Re: Media Contact Database
If it helps at all, I will be happy to host the database on my company's server.
This would be a 'real' database (MySQL), rather than the YahooGroups default.
I'll also be happy to volunteer some time to write software that allows admins
to enter and edit the data and for others to browse.
I currently maintain a local newspaper list that I use for issuing press
releases for my products, etc. so I have some experience in this area.
Quoting DGHarrison <DGHarrison@...>:
> Thanks for the list of possible fields to be considered for a data base.
> One reason I haven't started plugging in data is because there is still
> so much discussion about what should be included. I think it is a
> mistake to start with a limited number of fields and then discover later
> that our data is marginally useful or limited in its applications.
> I've been browsing some of our Minnesota Leftist Rags' web sites and
> finding that they are very careful to make it difficult for the public
> to communicate with them. Information you need is not readily available.
> They are like elitists in gated communities, with door guards and access
> codes to keep the public from reaching a human being on the inside.
> There are so many obstacles that a casual observer would give up, but
> needing the information for profession reasons requires an archeological
> dig on these web sites. I'm not going to move all that earth and bull
> crap, only to have to move it all over again. So, I'll wait to see what
> is really going to be required for this data base.
> It seems to me that we are reinventing the wheel here. Doesn't anyone
> have a "standard" media list that we can use as an example. I find it
> rather constricting to use the limited format of YahooGroups, which
> makes it feel like we're pounding a square peg into a round hole. We
> really should determine what information is essential for our database,
> and then see what platforms support our needs. If YahooGroups only
> allows for 10 fields and we need, say, 15, then we're potentially
> wasting a lot of time gathering only part of the information needed. At
> the same time, we don't want to gather unnecessary information. I'll
> admit that publication deadlines would be an unnecessary field, since we
> are not likely to be seeking ink in the less frequently published
> journals (it is good to keep it in mind for local, saturation campaigns
> In the YahooGroup data base, I noticed that there was no field for
> STATE. Sorting by state would be mighty useful for both state RLC
> chapters and the guy who has to maintain the media list for a particular
> state. I sure wouldn't want to have to scour thousands of records to
> find the few I am responsible to keep updated.
> Also, someone mentioned that particular states may not take kindly to
> certain issues. There's no sense in poking anyone in the eye if it can
> be avoided. In other words, maybe a little targeted dissemination is
> warranted, and that means we need to be able to exempt some states from
> receiving a news blitz that would do more harm than good. The danger of
> having "black out" regions, however, is that we may be lulled into
> hypocrisy if we don't watch out. We don't want to be painting two
> different faces on any issue, as that would seriously undermine our
> credibility. Perhaps we just need to be sure to pick our battles for
> news releases carefully, so we can present issues -- like Real ID --
> that have significant impact on everyone, no matter what their politics.
> Doug Harrison
> westmiller@... wrote:
> > From: "Chuck Seberg" <pusherprop3@...>
> > > My other concerns still stand.
> > You're correct about a direct import from csv to SQL: the fields and
> > types do have to match. However, there are dozens of programming
> > methods aside from those two facilities that can be used to make a
> > conversion of the field structure, type and sequence for all records
> > from one to the other.
> > Having said that, I don't have the time to convert my existing
> > media database to either Yahoo! DB or SQL. There are over 800
> > records in FoxPro (dBase) DBF format, but mostly with emails only.
> > Here's my structure, which may be useful in deciding on fields:
> > R_Media.DBF Structure
> > Field Field Name Type
> > 1 MEMID Character 8
> > 2 C_ACT Character 1
> > 3 C_MED Character 4
> > 4 C_WEB Character 4
> > 5 C_RAT Character 4
> > 6 C_MAR Character 4
> > 7 MAILNAME Character 50
> > 8 ORGAN Character 35
> > 9 TITLE Character 30
> > 10 SALUT Character 5
> > 11 FNAME Character 12
> > 12 LNAME Character 20
> > 13 ADDRESS Character 30
> > 14 ADDRHEAD Character 25
> > 15 CITY Character 25
> > 16 ST Character 2
> > 17 ZIP Character 10
> > 18 CTY Character 3
> > 19 RGN Character 7
> > 20 ONPHONE Character 10
> > 21 HMPHONE Character 10
> > 22 WKPHONE Character 10
> > 23 WKEXT Character 6
> > 24 FXPHONE Character 10
> > 25 ALTPHONE Character 10
> > 26 E_MAIL Character 45
> > 27 E_ALT Character 45
> > 28 E_SITE Character 50
> > 29 CON_DIST Character 2
> > 30 C_SRC Character 4
> > 31 C_ADV Character 4
> > 32 C_MESS Character 30
> > 33 C_MAIL Character 30
> > 34 D_ADDED Date 8
> > 35 D_UPDATED Date 8
> > 36 C_REC Character 3
> > 37 NOTES Memo 10
> > ** Total ** 575
> > The first set of C_xxx fields are Coded for ACTive, MEDia
> > (TV/Radio/etc),
> > WEB presence, RATing (National, State, Local, etc), MARket (Metro code).
> > The second set code for SRC (Source of the info), ADV (Flag for our
> > advertising on that media, MESSages (What we've sent that person) and
> > MAIL (The media's preference for submissions)
> > Bill
> > ------------------------------------------------------------------------
> > Yahoo! Groups Links
> > * To visit your group on the web, go to:
> > http://groups.yahoo.com/group/RLC-Action/
> > * To unsubscribe from this group, send an email to:
> > RLC-Actionemail@example.com
> > <mailto:RLC-Actionfirstname.lastname@example.org?subject=Unsubscribe>
> > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> > Service <http://docs.yahoo.com/info/terms/>.
- On Wed, 1 Jun 2005, Mike Bryant wrote:
> If it helps at all, I will be happy to host the database on my company's server.Hi Mike,
> This would be a 'real' database (MySQL), rather than the YahooGroups default.
> I'll also be happy to volunteer some time to write software that allows admins
> to enter and edit the data and for others to browse.
Your help would be great. I've already created a MySQL database and an
sftp user account on a virtual server that is colocated in downtown LA.
I would be happy to give you either sftp access to upload files and/or
shell access if you want to access the MySQL client directly on my server.
I'm happy to help no matter whose server is being used. My server is
setup for virtual hosting, so having multiple users is not a problem.
This database is my first attempt at programming in PHP although I am not
opposed to using another scripting language.