PHP 和 Oracle 可以互相传递复杂类型吗？
我想使用 PHP 将 (key1, key2) 数组传递/绑定到 Oracle PL/SQL 存储过程。我能够绑定原始类型和原始类型数组，但还没有找到来回传递复杂数据类型的方法。
这是不支持的吗？到目前为止，我一直不得不传递多个数组（一个数组对应复杂类型中的每个子类型），然后依赖它们的索引在过程中重新构造它们。
I want to pass/bind an array of (key1, key2) to an Oracle PL/SQL stored procedure using PHP. I'm able to bind primitive types and arrays of primitive types, but haven't found a way to pass complex datatypes back and forth.
Is this unsupported? So far I've been having to pass along multiple arrays -- one for each subtype in my complex type -- and then depend on their indexes to reconstitute them in the procedure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
好像不支持。
oci_bind_array_by_name()和oci_bind_by_name()似乎只能传递原始类型。 文档没有显示任何其他可能性。共享对象/结构/复杂类型并不容易，因为不同语言中对象的表示可能彼此相差甚远。例如，memcached 允许存储来自任何语言的对象，该语言具有将对象从其自身表示形式转换为 memcached 表示形式的库，反之亦然。
如果 oci8 有一个 PHP 散列/对象与 PL/SQL 中复杂类型之间的转换器，您就可以做到这一点，但事实并非如此。
您只需对
oci_bind_by_name()进行多次调用，然后根据哈希/复杂类型的每个键的需要使用尽可能多的参数来调用您的过程。Does not seem supported.
oci_bind_array_by_name()andoci_bind_by_name()seems to only be able to pass primitive types. The documentation does not show any other possibility.Sharing object/structures/complex types is not easy, as the representation of an object in different languages can be far from each other. For example
memcachedallow to store objects from any language that has a library that convert objects from its own representation to memcached one and vice versa.You could do it if oci8 had a converter between PHP hashes/objects to complex types in PL/SQL but that's not the case.
You just can make several calls to
oci_bind_by_name()and so call your procedure with as many arguments as needed for each key of your hash/complex type.为什么不将对象的状态序列化为 XML？
目前，将对象序列化为 XML 是很常见的做法，以便它们可以以与语言/平台无关的方式在 Web 上传递。为什么不做同样的事情并将其作为 varchar 存储在数据库中。
注意：这种方法的明显缺陷是您无法以干净的方式通过对象的属性来选择数据库中的字段，因为它将对象的多个属性混合在数据库的一个字段中。 em>
如果您确实需要可搜索对象的属性，则需要将对象的每个属性中的数据分解到各自的字段中。
Why don't you serialize the object's state as XML?
Currently it's pretty common practice to searilize objects as XML so they can be passed across the web in a language/platform agnostic manner. Why not do the same and store it as a varchar in the DB.
Note: The glaring deficiency of this method is you won't be able to select fields in the database by attributes of the object in a clean manner because it mixes multiple attributes of the object in one field of the database.
If you do need the attributes of the object to be searchable, you'll need to break out the data from each of the object's attributes into their own respective fields.
根据 Evans 的建议，我建议使用 JSON。 PHP 和 Oracle 可以编码/解码 JSON，它是比 XML 简洁得多。
无论您选择哪种方式，序列化可能都是正确的选择。也就是说，我建议不要将原始 JSON 存储在 varchar 字段中 - Oracle 能够（使用上面链接的工具）解释 JSON 并生成 JSON 响应。
Further to Evans's suggestion, I'd recommend using JSON. Both PHP and Oracle can encode/decode JSON and it's substantially less verbose than XML.
Whichever you go for, serialization is probably the way to go. That said, I would advise against storing the raw JSON in a varchar field - Oracle is able (with the tool linked above) to both interpret JSON and generate JSON responses.
JSON 更“轻量”，但我真的不清楚为什么有人希望在 Oracle 中使用 JSON 并拥有 Oracle XML 处理功能和可供使用的 XML DB 的强大功能。序列化讨论消失了，因为 Oracle 可以将 XML“分解”为关系表，以实现高性能和可访问性，而无需开发人员编写一行代码（也不必依赖未经验证的 json 项目），并且同样透明地以 XML 形式检索它。
另一个观察结果是，按照上面的建议保持“与数据库无关”，虽然可移植，但极大地限制了开发人员利用当今数据库引擎提供的强大功能的能力。
我知道这个评论是“迟到的”，但是这些陈述在上述答案时在 Oracle 10g 中都是正确的，我确信人们仍然面临这个特殊的挑战
我对所有使用 PHP 和 Oracle 的人的强烈建议是使用 XML 并利用 Oracle 令人难以置信的 XML 处理功能。
JSON is "lighter" but I'm really unclear as to why would anyone want to use JSON in Oracle with the power of Oracle XML handling capabilities and XML DB at one's disposal. The serialisation discussion disappears as Oracle can "shred" XML into relational tables for high performance and accessibility without the developer writing a single line of code (and also without having to rely on unproven json projects) - and likewise retrieve it as XML transparently.
Another observation is that to remain "database agnostic" as recommended above, while portable, dramaticly limits the developer's ability to take advantage of the massively powerful features that today's database engines provide.
I'm aware that this commentary is "late" however these statements all held true in Oracle 10g at the time of the answers above and I'm sure people still face this particular challenge
My strong recommendation for all out there using PHP and Oracle is use XML and take advantage of Oracles incredible XML handling features.