2016-08-24 22:36
浏览 152


I know this is a loaded question, but I think what I'm doing right now is probably the wrong way to go about things, so I'd like some input as to what is best practice.

Currently I have an array of actors. Let's say NSArray *actors in Objective-C. I want to pass this up to my PHP page for storage.

Right now I pass this up on HTTP POST by turning the array into a string such as this:

&actors=Joe Allen*Dave Smith*Mary Johnson*Alice Burg?movietitle=Runner

When it gets to PHP I'm then passing it to MySQL via a Stored Procedure call like this:

CALL Add_Movie(movietitle, actors);

And then in my sproc is where I 'explode' the actors by * to save them in the correct table. I do the reverse to get the actors back. It's gotten even trickier for me when I've wanted to separate first/last names.

Anyway, this seems really hacky to me. What's best practice for an array transfer over HTTP to SQL storage and back?

图片转代码服务由CSDN问答提供 功能建议

我知道这是一个加载的问题,但我认为我现在所做的可能是错误的方法 关于事情,所以我想对什么是最佳实践有所了解。

目前我有一系列演员。 我们在Objective-C中说 NSArray * actors 。 我想把它传递到我的PHP页面进行存储。

现在我通过将数组转换为像这样的字符串来传递 HTTP POST

 & actors = Joe Allen * Dave Smith * Mary Johnson * Alice Burg?movietitle = Runner 


  CALL Add_Movie(movietitle,actors); 

然后在我的sproc中,我通过 * “爆炸”演员将它们保存在正确的表中。 我反过来让演员回来。 当我想要分隔名字/姓氏时,对我来说更加棘手。

无论如何,这对我来说似乎真的很烦人。 通过HTTP到SQL存储并返回数组传输的最佳实践是什么?

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 邀请回答

3条回答 默认 最新

  • duancheng6221 2016-08-25 00:54
    1. Pick an established serialization format, don't try to roll your own.
      • Established formats have pre-written libraries to handle things like encoding complex types and encapsulating/escaping strings/data.
    2. Pick a serialization format that is well-defined and supported by both ends, that is IOS/ObjC and PHP.
      • You don't want to waste time writing new libraries to implement unsupported formats.
    3. Don't store serialized data in an RDBMS, particularly MySQL.
      • Storage, access, indexing, etc all become difficult or impossible to do or do well.
      • If you're simply looking for a key-value store there are much better options than MySQL.

    That said, there are two standout candidate formats:

    • JSON: The lingua franca of the modern internet. Simple, lightweight, flexible, and damn-near everything understands it.
    • XML: JSON's bloated uncle. Clunky, verbose, and generally a big pain in the ass; but if you want to impose typing, structure, and other such things on your data exchange format you could do worse than XML.

    In the big picture what you've described sounds like the exact case for defining an REST API.

    解决 无用
    打赏 举报